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.
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.
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.
Previous Message
