[
Lists Home |
Date Index |
Thread Index
]
On Wed, 2002-06-26 at 05:04, Jonathan Borden wrote:
> Bullard, Claude L (Len) wrote:
> >
> > Hoping sincerely that your book is one that enables right choice
> > based on well-understood requirements. Best of luck.
> >
>
> Some of my requirements for a schema language:
>
> 1) No surprises. I want to be able to express the constraints for a desired
> collection of documents in a straightforward fashion. I don't want the
> schema language to GPF for unexpected reasons.
>
> 2) Good power/complexity ratio. I will accept complexity only if it is
> accompanied by sufficient power. If I am going to slug through learning a
> new language, I expect to be rewarded for doing so.
>
> 3) Easy for easy tasks. I don't want to make everything complicated. See
> above.
I think that the 3 points are linked and that most of the time
simplicity and flexibility are closely related at least from a user POV.
Complexity begins with added restrictions aimed to make life easier for
the implementers and which when not assimilated by users look
unpredictable and are seen as GPF. And ultimately, when too many of
these restrictions are added, the implementers themselves get confused.
> Off the top of my head that's a few. For example, we've long been told that
> XML DTDs dropped the "&" construct because of the cost/benefit ratio -- cost
> for the implementation that is, because this construct is rather intuitive
> for people designing document formats (translation: it makes expressing
> certain document constraints _easy_). Now it seems that RELAXNG has brought
> back the "&" at least in the form of "interleave" yet without any great
> increase in complexity indeed the language is simpler than XML Schema. So
> that is a _good thing_ right?
This is an example where the restrictions on xs:all create complexity
for the users and the lack of restrictions on RNG interleave is source
of simplicity.
What's interesting is that in the derivative algorithm described by
James Clark, interleave is barely more complex than ordered groups: in
my implementation, the main derivation method is 11 python instructions
for ordered groups and 13 instructions for interleave. What's also worth
noting is that interleave derivation would have had to be implemented
anyway since it's used to derive patterns against attribute nodes and
that at the end of the day, interleave doesn't add complexity for
implementers either.
The restrictions on xs:all appear then to have been dictated by the
concern of exponential blowup for implementations using a finite state
machine and here again, what's interesting is that Murata Makoto has
recently published a paper [1] describing a two phases technique based
on FSM which should avoid the exponential blowup for unordered content
models.
[1] http://www.kurims.kyoto-u.ac.jp/~hahosoya/papers/attelm.ps
There is probably a lesson to learn here for specification writers: yes
this is important to make sure that a specification can be implemented
at specification time. OTH there is a balance to find and being too
close to a specific implementation algorithm may impact the useability
of the spec without improving its implementability!
Eric
> Jonathan
>
--
See you in San Diego.
http://conferences.oreillynet.com/os2002/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
|
