XSchema: ease of use (design goal 5)

[Michael Kay]

>I have posted a proposed draft XSchema document at
>http://www.ccil.org/~cowan/XSchema-draft-19980601.txt .


I think the most important point this paper states (and
demonstrates) is:

>human beings will find them [XSchemas] painful to write by
hand, due to their great redundancy compared to DTDs.

This conflicts directly with design goal 5, which states:

>XSchema documents shall be easy to create, read, and
modify, and shall
provide authoring support.

When I first looked at the idea of encoding DTDs in XML a
couple of months ago, one of my motivations was that I find
the current DTD syntax very ugly, and I came to the same
conclusion: whatever the merits of an XML encoding, it would
not be user-friendly. (My feelings about XSL are the same).
XML works well as a markup language for text; it also works
well as a markup language for data; but it is very poor as a
human-readable lexical encoding of a language with rich
syntax.

Trying to solve this problem my imagination started running
away with me:

* one of the limitations of XML is that we cannot constrain
the content of
character strings (in attributes or PCDATA) in a DTD
* the ideal way to define such constraints would be with
regular expressions or BNF production rules
* let's call "XML with constrained character strings" Rich
XML or RXML. Of course an RXML document is an XML document;
it just has some "content validity" rules in addition to the
XML well-formedness and validation rules.
* we can imagine a "pre-parser" which takes an RXML document
and automatically generates additional XML markup so that
all the syntax is now fully accessible as elements and
attributes. This pre-parsed document would no longer be
easily readable, but it would be easily processable using
standard XML tools
* We could encode both the current DTD information and the
additional constraints in RXML
* if we use RXML rather than plain XML to encode our DTD, we
can continue to use BNF-like production rules written as
text, while still being able to process the thing using
general-purpose XML machinery.

In other words, I think we have here not only a solution to
the usability dilemma posed at the beginning of this
posting, but a generally useful extension to the
capabilities of XML.

But sorry, I don't intend to devote my life to it!

Mike Kay
M.H.Kay at eng.icl.co.uk


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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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)