OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding the vote on XML Schema.



From: Murali Mani <mani@CS.UCLA.EDU>

 >There should be good reasons why two very
>prolific mathematicians and XML practitioners such as James Clark and
>Makoto Murata have decided not to adopt fully the solution proposed by XML
>Schema

Yes.  But why should anyone expect there to be unanimity?   Surely the big
thing that we can learn from XML Schemas is that the expectation that we can
have a single language--no matter how big or small, elegant or rich,
feathered or porpoise-like--that is suitable for everyone is a fantasy.
Which is why questions of whether we prefer ambiguous to unambigous
grammars, or the Islamic calendar to the Gregorian calendar, should be dealt
with _after_ we have built a suitable framework for modular but controllable
schemas.  With a modular framework, the stakes are lower, we are not forced
to make decisions on issues which have no single obvious winnner.

Without modularity we are forced into an unpleasant world of winners and
losers, depending on whether our application's needs are consonant with the
ones weighed highly by the particular schema language developers.

Merely saying "XML Schemas bad!  RELAX good!" keeps the cart before the
horse.  If there is no modularity or ability to plug-n-play with different
kinds of schema, then every little engineering trade-off has to be subjected
to exhaustive discussion (as in XML Schemas) with no guarantee that the
result will satisfy everyone.

It is good to have a nice powerful, branded language that can support test
suites and be reasoned about enough to allow efficient storage and querying.
But does that require a monolith?

Cheers
Rick Jelliffe

P.S. Just before RELAX and TREX, there was the excellent DSD [2] too.  It
has many useful ideas.
[1] http://www.liss.ic.ac.uk/hypermail/xml-dev/xml-dev-Dec-1999/0687.html
[2] http://www.xmlhack.com/read.php?item=135