How to Design the XML Content Environment
If you are building a Web content-management solution, you may consider
coding the textual content in XML. That certainly is not a requirement.
However, one of the advan-tages of coding content in XML is the promise that
content can be recombined and repurposed to create customized content
deliverables.
Reusable Document Objects
If reuse is a major goal of coding content in XML, then the XML design
should facilitate reuse. Here, the design should focus on the creation of small
documents that contain con-cise topics. Because each piece of content can stand
alone, it becomes a relatively easy task to combine pieces of content in new
ways.
It is important to understand how you intend to reuse content and then
to design the XML encoding and eventually the content storage to support that
goal. Let’s suppose, for example, that our content is scientific journals. What
is the element of content reuse in this scenario? At first, glance it is the
articles. It makes little sense to reuse anything but a complete article. Our
XML encoding for the journal should enable each article to be a small, reusable
document.
But if we take a close look, we can imagine that two other elements
within the article might be reused as well. The first is the art. Photos and
illustrations might have a reuse value of their own. Likewise, tables that
summarize findings in the article might have use as an independent content
object. What can we do in our XML design to support the spe-cific reuse of
these subelements.
Again, we must go back to the idea that each piece of reusable content
is a small docu-ment. This means that each figure and table in the journal
article is its own little docu-ment, is stored independently, and is called
into this article or any other content-based product when the product is
assembled for delivery.
XML Document Design Principles
Many times users of XML-based content-management systems come from an
SGML background. Certainly conversion of data from SGML to XML is quite
straightforward. However, the straightforward conversion of SGML documents into
XML documents may not be the best design solution for data to be managed in a
content-management system. If your original DTD was designed for a monolithic
document to drive a print product, it most likely will not provide the
functionality you want when you make an investment in a content-management
solution.
Your content-management system will only be as flexible and versatile as
the structures you impose on it. If you simply convert your monolithic SGML
into monolithic XML (such as a large aircraft maintenance manual coded in
compliance with ATA Spec 2100), you will end up managing the content as a large
document that has very little potential for reuse in the future. Such large
documents also have a huge impact on system performance.
An alternate approach to designing a monolithic XML tag set is to create
small docu-ment definitions. Often times these small document definitions are
based on an object model for reuse. Let’s consider a scientific journal once
more. In the days of SGML, we would define a DTD for the whole journal. This
would imply the journal issue, contain-ing all articles are managed and used as
a unit. A slightly better approach would be to define a schema for the article.
Then, we could call the article schema (and content stored on an article basis)
as appropriate to construct the journal. We would store and use articles as
independent information objects.
An even better approach would be to fragment the article into other
useful objects or small documents that themselves might be reused. Here, we
could envision having a schema for the journal that includes the schema for
articles. The article schema might include other small XML documents such as
the abstract, the citation header information for the article, the summary
tables, and all graphics. Each of these content objects could then be managed
independently, providing the functionality expected when we decided to use a
content-management system.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.