 Have you hadsimilar experiences, or have an opinion on content management with XML? | |
| Talk back to the author and XML.com . | |
During a recent development effort, one of our clients was alarmed at the conversion costs of the proposed XML-based content management system compared to the existing MS Word-based process. This was just one instance of an alarming trend of balking at XML-based systems in favor of using public web folders, indexed by some full-text search engine, as part of a local intranet. In the short run, these edit, drop, and index solutions have some appealing features, including low development and conversion costs. But they are short-lived systems that either wither from lack of functionality or rapidly outgrow their design.
Fortunately, the initial objections to the cost of building an XML-based content repository have become fairly predictable. In most cases they are based on misconceptions about XML or on an overly optimistic view of alternative approaches.
Even though implementing an XML-based content management system is not always the best approach for an organization, any architectural decision should be made only after thoroughly overcoming the common misconceptions of the technology involved. The list of questions below is intended to be a guide for IT professionals to discuss intelligently the pros and cons of developing an XML document repository.
Why does my small group of authors need an XML solution?
Although it is true that the value of an XML-based content management system increases with the number of authors and document complexity, even a small authoring group can benefit from an XML solution. The core benefits involve document standardization, profiling, and growth. Authoring in XML provides a natural structure to ensure documents adhere to corporate guidelines through the use of DTDs or schemas.
By separating the style of a document from its content and structure, XML repositories can distribute different views of documents to different audiences, all from a single source document. In MS Word or HTML systems, a separate version of the document is needed for each view. Lastly, XML authoring systems provides a solid foundation for future growth as they are platform independent and can be upgraded with relative ease.
Isn't XML used for business-to-business exchanges as a replacement for EDI?
One of the main reasons for the surge of XML-based technology in the marketplace is its application in business-to-business supply chain management. As companies continually look to streamline electronic commerce solutions, XML has emerged as a perfect mechanism to handle the requirements of exchanging product and transaction information. One unexpected side effect of the use of XML for supply chain management is that new users of the technology are led to believe that XML is suited only for this application.
However, XML evolved from SGML, which was designed to manage large volumes of textual information. For more than fifteen years, SGML has been used in publishing, telecommunications, and manufacturing companies to solve the same content management problems that XML addresses today. Even though XML does not support all of SGML's functionality, it enjoys wider acceptance, which positions it well to solve most of today's content management problems.
Why do my authors have to learn a programming language to create documents?
Authoring effectively in XML requires a sound understanding of the content as well as the structure of documents. Since authors no longer have to worry about document styling, they can concentrate on the core content and structure of their work. Getting started with XML is becoming easier since applications that use textual markup are now commonplace (HTML, etc.). Adapting a controlled set of styles is a much less daunting task than learning a programming language.
Why are XML consultants so expensive?
The two main contributors to the cost associated with using XML consultants are specialized knowledge and risk. Often an XML conversion project requirements some initial design work that, if done correctly, will not have to be modified very frequently. Companies should not be creating DTDs, designing XML authoring platforms, or configuring search engines more than a few times a year.
Consequently, it does not make sense for most organizations to include those skills in its full time staff. Additionally, any architectural mistake committed during the design stage of these projects could result in very expensive rework down the road well after implementation. For these reasons, despite the additional cost, it is often wise to utilize outside expertise during the critical stages of an XML project.
Why don't we just use MS Word?
For all of the benefits of MS Word and for all it has done in the world of word processing and office automation, it could be the single biggest obstacle to wide commercial acceptance of XML authoring solutions. Microsoft markets its style templates and HTML conversion features as the only packages that customers need for enterprise authoring. Additionally, with MS Word available on virtually every corporate desktop, you can quickly and inexpensively start authoring documentation with it. But the fact of the matter is that Word does not support XML directly, and it cannot be easily integrated into a structured content repository. However, add-ins to Word to support XML export are starting to appear on the market.
Why don't we author directly in HTML?
Authoring directly in HTML may be quickest way to get new documentation onto a web site. However, in addition to many of the same consistency problems that exist when authoring in MS Word, there are some additional limitations as well. First, creating a repository of HTML files optimized for web viewing will inevitably create problems for printed output. HTML does not support many standard page layout, font, and line formatting features necessary for a production print environment. In short, if an organization chooses to create a repository of HTML documents, it will either have to greatly scale back its print capabilities or utilize only a subset of HTML features that will look appropriate when printed. Or they will be forced to create two versions of HTML, one for online viewing and one for printing.
Even if an organization does not need to support document printing, creating a corporate knowledge base in HTML has other limitations. Authors will not be able to identify document components explicitly for specialized searching or formatting. Additionally, there is no way to enforce business rules for creating documentation by verifying HTML against an approved document type definition.
Why do we need XML if we are already using a relational database to track documents?
Using a relational database to store large volumes of textual content along with its metadata provides a solid infrastructure to build the security, version control, and workflow components needed in a content management system. However, this technique alone does not ensure that the structure of distributed documentation will be preserved.
In conclusion, with the content management marketplace becoming competitive, the costs of XML-based authoring and repository systems are going to be questioned more than ever. This scrutiny will not be based on the uncertainty of the benefits of these systems, as in the past, but, rather, on the growing number of low cost substitute systems touting comparable features. Only after understanding the clouded atmosphere surrounding XML-based systems, and anticipating the common misconceptions about the technology, can one justify such a system in a business setting.
|
|
Have you had similar experiences, or have an opinion on content management with XML? Talk back to the author and XML.com. |
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- XML and Microsoft Word
2001-04-12 13:44:54 Bjorn Nelson [Reply]
I'd like to comment on the section that notes the lack of XML support in Microsoft Word. One fairly comprehensive solution to this problem is WorX SE from HyperVision, Ltd. ( http://www.hvltd.com ). This comment was intended as an objective clarification to the article, not as an endorsement. =)
- XML-Based Authoring Systems
2001-03-23 07:22:14 sriram bhamidipati [Reply]
Please provide a small overview of architecture.
On our side, we have problems in defining the input and retrieval
mechanisms or, programs of XML content.
for example, if we use forms in HTML, how easily
can the backend get the forms data as XML for strorage and processing?
We have a mix and match of Netscape 4.x and IE 5.x browsers
One supports XSLT and one doesn't.
so, there are architecture issues and how do you
work these out?
- XML-Based Authoring Systems
2001-04-05 10:28:49 Brian Buehling [Reply]
Although no architecture will fit every situation, hopefully these responses will help out:
1) Actually, data submitted through HTML forms can be readily stored as XML data. Once the form fields are mapped to XML elements, extracting the data from each field and inserting the appropriate markup is straight forward.
2) You can still use XSLT to render XML documents in HTML even if you need to support users with older browsers. However, the XSLT transformation will have to be moved to the server (JSP, Java Servlets, ASP, etc) so the browser recieves only HTML.
Brian Buehling
buehling@dakota-systems.net
- XML-Based Authoring Systems
- XML based Authoring Systems
2001-03-23 02:45:03 Martin Vanderjagt [Reply]
Hi,
We 've been working on a knowledgable DTD for our product structure for about a year. We 've been customizing the authoring tool (XMetaL) for every change in the DTD.
But now that authors can work with it (and check their documents in into an XML database: eXcelon) we experience the full benefit: different publications on different websites without any latency, overhead or loss of quality.
- The authors are enthousiastic because they can edit WYSIWYG (MS-Word like).
- The webmanagers are enthousiastic because they reach their goals with only initial efforts.
There is a question though:
- How to reach the goal of text element reusage without taking the text element out of context
OR
- How to recreate context for re-usable text elements.
We do some of this re-usage ofcourse, but a more generalised structure might be possible.
Kind regards,
Martijn van der Jagt
architect of:
http://www.sopho.philips.com
- XML based Authoring Systems
2001-10-26 11:42:51 Elayne Sandahl [Reply]
Martin,
I am a help developer under contract to the Canadian Department of National Defence. Your question raises issues that I face when using XML to create text elements used in online help.
And the problem is that the instant text becomes context-sensitive, it is not re-usable. For example, the text used as part of a corporate policy ("The Company shall provide $250 for fitness activity per employee. See Ref 1.1.a")can also be used in a marketing brochure or on a web site for a career fair, however, the tone is different. The context is sensitive.
The only suggestion I have would be to categorize or class your text elements to a lesser degree of refinment, then within that class (e.g. fitness), create elements for each subject (FitnessCorpPol, Fitness, FitnessEmployeeBenefit), with a standard framework for the different contexts required.
I am trying to find someone who has successfully used XML to create online help systems, including links, search and index capabilities.
Regards,
Elayne Sandahl
The Fiddlehead Technology Group
- XML based Authoring Systems
2001-04-05 12:01:13 Brian Buehling [Reply]
One way this can be accomplished is to define elements in your DTD that are only used for editing and storing XML components. For example, we could define an "editdoc" element that allows authors to create re-usable content without the context elements required in the a "publishdoc" element. Similarly you might want to store individual XML components in your repository independent of your publication specific rules.
However, taking full advantage of re-usable content presents one of the most difficult challenges of XML. The reason why this objective is so difficult to accomplish is that the solution involves more than technology. Ultimately, publication coordinators, authors and editors need to change from "publication-specific" to "content-specific" mentality creating content.
Brian Buehling
buehling@dakota-systems.net
- XML based Authoring Systems
