documenting schemas/DTDs

[Rick Jelliffe]

From: Tim Bray <tbray at textuality.com>

 > Meaning is  only conveyed by
>
> (a) running code, or
> (b) human-readable prose.
>
>To generate (a), you have to have (b) first.

I would go further than this, and say that if a) does not allow
retrieval of b), the system is not suitable for portions of a document
production chain in which human intervention is required. So, not only
direct documentation of the schema, but the schema should also provide a
minimal level of diagnostic information.

The systems THETIS and Schematron take the approach that a) and b)
should to a great extent be coupled. In Schematron, machine-processable
tests are attributes on text elements which state the assertion that is
being made.

I think there is a fundamental unresolved issue that there are lot of
situations in which we can use various kinds of schema validation
information: creating systems & tools, creating documents, validating
documents, giving error messages, giving diagnostics, triggering
defaulting behaviour, being used to allow logical combination of schema,
and so on.

To support these adequately, I believe a general-purpose schema language
has to not only tightly integrate human-readable components, but also
provide clear machine-processable enumerations of each possible error (&
categorizing it against som controlled vocabulary) in a way that allows
schema-processors to have a standard API that can be used to create
validators, editors, etc.  For an example of such an approach, see
proposal
http://www.ascc.net/xml/en/utf-8/error.html

Rick Jelliffe



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)