[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XSchema: ease of use (design goal 5)

  • From: "Michael Kay" <M.H.Kay@e...>
  • To: "XML Dev" <xml-dev@i...>
  • Date: Tue, 2 Jun 1998 15:57:08 +0100

design goal
>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

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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.