Lists Home |
Date Index |
- From: "Michael Kay" <M.H.Kay@eng.icl.co.uk>
- To: "XML Dev" <email@example.com>
- Date: Tue, 2 Jun 1998 15:57:08 +0100
>I have posted a proposed draft XSchema document at
I think the most important point this paper states (and
>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
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!
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)