14.5. Which One and What For?
If we recap the three different forms we have seen to include simple comments, we may use xs:documentation:
<xs:element name="author" type="author"> <xs:annotation> <xs:documentation xml:lang="en"> The author of a book. </xs:documentation> <xs:documentation xml:lang="fr"> Designe l'auteur d'un livre. </xs:documentation> </xs:annotation> </xs:element>
Or foreign attributes:
<xs:element name="author" type="author" doc:doc="This element describes the author of a book." xmlns:doc="http://dyomedea.com/ns/doc"/>
Or XML 1.0 comments:
<xs:element name="author" type="author"> <!-- This element describes the author of a book. --> </xs:element>
Which one is more appropriate? There is no simple answer, since it depends on which form is supported by the set of tools you choose, and on what you want to do out of these comments. That being said, does that really matter? The hard work is to include relevant comments in your schemas and to keep them up to date. The format itself is not really that important, and each approach is only one XSLT transformation away from the two other alternatives!
The same applies to all the meta-information that we included in our schemas: they do not break the schema and can be processed by any schema processor but will be ignored by most of them! Adding them is useful only if one has an application in mind, and the choice of the format will be determined by the constraints of this application.
Finally, we must note that we have only presented schema-centric options, in which information is added within W3C XML Schema that conforms to the Recommendation. Other options exist, which may be object-oriented design-centric (generating schemas from UML specifications) or adjunct-centric (describing the schema adjunct outside of the W3C XML Schema document). Also, some new inventive packaging could be invented, such as formats that would group different resources (schemas, transformations, stylesheets, etc.) for an information item under a single umbrella, and perhaps recompose the traditional "per function" packaging, depending on the composition done by the application.
Copyright © 2002 O'Reilly & Associates. All rights reserved.