Why
turn to a schema?
If you need software to check on the type of data entered, as in a
conventional database, schemas make this easier.
Schemas, though, are not supported by every tool. Make the vendor prove
that their software handles schemas as well as DTDs.
Use the
formal models to validate
Every time you create a new object in a particular class, it must conform
to the standards you have defined. The parser consults your DTD or schema,
and checks to make sure that you have, in fact, followed the rules. If
not, you get an error, or downright refusal to display anything.
Using a true XML editor such as FrameMaker 7 or Arbortext Epic lets you
check validity as you go. In turn, the need for validation drives you
toward software tools that can check, or guarantee valid content.
Communicate the
structure--and revise
Create a table of contents or giant outline for all your content.
Recognize that the reusable objects will reappear here, there, and
everywhere.
This kind of outline gets out of date as soon as you go live. So consider
it only a planning document.
For meetings, create diagrams indicating the structure of a particular
group's favorite DTDs, so they understand the structures they must now
work within. Discuss, and modify.
Generate authoring forms from the
model
From the author's point of view, this approach is just "fill in the
blanks." Behind the scenes, the software applies the correct XML tags, so
that the resulting document is valid and well-formed XML.
Advantages:
- Authors do not need to know the model.
- You hide the tags from authors who might be overwhelmed.
- Forms are OK for short, regular, objects.
Disadvantages
- Professional authors feel constricted, want to see the structure
displayed, want to be able to override the structure, then have their
efforts validated after working freestyle for a while.
- Forms do not work for material that stretches over more than a few
pages.
- Forms are fixed; you need a programmer to change one.
Manage your components
Create a database to track and report on questions like these:
- How many objects have you defined?
- How many instances do you expect with the higher-level objects (the root
elements defined by DTDs, for example, or publications)?
- Do you have authors assigned to every instance?
- How many objects, total, are going to be moving through your system on
an average day, or in an average week?
- How many objects will be "live" in the workflow at any one time?
Complete details on how to create a DTD:
Making an XML DTD Step by Step
Next:
Join the
enterprise-wide data model
