Recently in XSLT Category
For some research I am doing, I would like to talk to people who are using ETL tools for transforming large volumes of content. If you have some thoughts about this, please contact me.
Some news from the W3C:
The XSL Working Group has published the First Public Working Draft of Extensible Stylesheet Language (XSL) Requirements Version 2.0. This document enumerates the collected requirements for a 2.0 version of XSL Formatting Objects (XSL-FO), not for XSLT. XSL-FO is widely deployed in industry and academia where multiple output forms (typically print and online) are needed from single source XML. It is used in many diverse applications and countries on a large number of implementations to create technical documentation, reports and contracts, terms and conditions, invoices and other forms processing, such as driver's licenses and postal forms. The XSL Working Group invites people to help prioritize the feature set of XSL 2.0 by completing a survey until the end of September 2008.
I talk to developers who have ideas about improving XLST. Now is your chance.
Well as the name of the blog suggests, the focus is on both technology and strategy. We have been at this long enough to come to the stunning conclusion that technology adoptions minus well-thought-out and sound business strategies are doomed to failure. (Now you know why we get paid the big bucks!) While obvious, the conclusion is also true. I have had the luxury of consulting with several clients over a long period of time. I like to think they are successful because they listen to me (and they do), but the bigger reason they are successful is that they use my input to inform well thought out business strategies. Sometimes these are operational (they want to save money, improve efficiency), but more often they are about the top line. They want to drive more revenue.
For commercial publishers this means bringing more product to market more quickly, customizing products, and developing derivative products (think of offerings like SafariU). For enterprises, this is also tied to bringing more product to market more quickly; think of a company like Autodesk using XML-based publishing and globalization to bring more products to more markets simultaneously. These are world-class projects based on XML that are bringing incredible value to their organizations, but--even more significantly--these are not the only efforts of their kind. Whereas in the early days of SGML the community could count projects of this type in perhaps the low double digits, I have long ago given up on trying to remember or catalog how many of these projects are out there backed by XML technology.
But not every project is as successful as the ones I have cited. Indeed these stand out as case studies of the best practices. Projects do fail and projects do falter, and I will reveal my bias here in saying that, especially in the recent few years, few projects fail because of the chosen technology. (All complex systems require significant customization! Who would have thunk it?) Much more often they fail because of problems with project management, lack of sufficient staffing, and shifting plans and execution when the inevitable problems arise. And these kinds of failures come right back to a failure in strategy, or at least a failure in realistically planning for a complex undertaking that is critical to organizational success.
So content strategies are indeed a critical half of this practice, but technology is the other half. Here as well a comparison to SGML is in order. Whereas in the days of SGML there were few vendors at the table, now there are literally scores. Even more importantly, none of the major vendors are missing, and one can make the argument that the major vendors are--or soon will be--the dominant players in the market. XML is central to the product and development platform strategies of Microsoft, Oracle, IBM, Sun, Adobe, and EMC. One can only speculate at the level of R&D dedicated to XML at these companies, but it is safe to say it is a lot. Just as impressive is the community of developers who work in XML daily. Most programmers working in contemporary languages like Java and C# use XML for all kinds of routine tasks, and XML data mapping and modeling tools are built into Visual Studio and many other development tools.
To be more specific, we intend to cover what we categorize as the range of XML products of most interest to business and IT professionals responsible for content management initiatives. These include:
- XML Repositories
- XML Content Management Platforms
- XML Editors
- XML Transformation and Publishing Tools
- XML Utilities, Middleware, and IDEs
- XML Forms
Among other things, we will be developing an online directory of these product lines (more on that in a future post). I have been informally cataloging the companies over the recent few weeks and I already have 60 to 70 companies without trying very hard. We expect to interact with these vendors, get details of the products and product roadmaps, and also work with them when appropriate on product strategy and projects like white papers and case studies.
So that's the news so far from here. Do get in touch if you have any questions, ideas, or complaints!
As Frank noted in our main blog and in the related press release, this blog is part of our launch this week of a new practice focused on the technologies, strategies, and best practices associated with using XML in content management. With this focus on XML, the new practice is broad--XML is fundamental to so many aspects of content management. Yet the focus on XML also compels us to look at content management through a certain lens. This begins with the vendor offerings, where nearly every platform, product, and tool has to meet anywhere from a few to myriad XML-related requirements. As XML and its related standards have evolved and matured, evaluating this support has become a more complex and considered task. The more complex and feature-rich the offering, the more difficult the task of evaluating its support.
And indeed, the offerings are becoming more complex, especially among platform vendors like Microsoft, IBM, and Oracle. Looking at SharePoint means evaluating it as a content management platform, but also looking specifically at how it supports technologies like XML forms interfaces, XML data and content feeds, and integration with the XML schemas underlying Microsoft Word and Excel. It also means looking at SOA interfaces and XML integration of Web Parts,and considering how developers and data analysts might want to utilize XML schema and XSLT in SharePoint application development. Depending on your requirements and applications, there could be a great deal more functionality for you to evaluate and explore. And that is just one platform.
But understanding the vendor--and open source--offerings is only one piece of the XML content management puzzle. Just as important as choosing the right tools are the strategic issues in planning for and later deploying these offerings. Organizations often don't spend enough time asking and answering the biggest and most important questions. What goals do they have for the technology? Cost savings? Revenue growth? Accelerated time to market? The ability to work globally? These general business requirements need to then be translated into more specific requirements, and only then do these requirements begin to point to specific technologies. If XML is part of the potential solution, organizations need to look at what standards might be a fit. If you produce product support content, perhaps DITA is a fit for you. If you are a publisher, you might look at XML-based metadata standards like XMP or PRISM.
Finally, XML doesn't exist in a content management vacuum, removed from the larger technology infrastructure that organizations have put in place. The platforms and tools must integrate well with technologies inside and outside the firewall; this is especially true as more software development is happening in the cloud and organizations are more readily embracing Software as a Service. One thing we have learned over the years is that XML is fundamental to two critical aspects of content management—for the encoding and management of the content itself (including the related metadata) and for the integration of the many component and related technologies that comprise and are related to content management. Lauren Wood wrote about this in 2002, David Guenette and I revisited it a year later, and the theme recurs in numerous Gilbane writings. The ubiquitous nature of XML makes the need for strategies and best practices more acute, and also points to the need to bring together the various stakeholders--notably the business people who have the content management requirements and the technologists who can help make the technology adoptions successful. Projects have the best chance of succeeding when these stakeholders are brought together to reach consensus first on business and technical requirements, and, later, to reach consensus on technology and approach.
As Frank noted, this is "New/Old" news for all of us involved with the new practice. I first discussed SGML with Frank in 1987 when I was at Mitre and responsible for a project to bring new technology to bear on creating specifications for government projects. Frank had recently launched his technology practice, Publishing Technology Management. Leonor was a client at Factory Mutual when I worked for Xyvision (now XyEnterprise) in the early 1990s. And I probably first met Mary at a GCA (now IDEAlliance) event during my Xyvision days and when she worked for a competitor, Datalogics. We are, in the polite vernacular of the day, seasoned professionals.
So welcome to the new blog. Watch this space for more details as we announce some of the offerings and initiatives. I plan to blog actively here, so please add the RSS feed if you prefer to digest your material that way. If you have ideas or suggestions, don't hesitate to post here or contact me or any of the other analysts directly. We look forward to the interaction!