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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] choice, sequence, all: 'easy' XML Schema question

[ Lists Home | Date Index | Thread Index ]

Henry S. Thompson wrote:
 > John Graybeal <graybeal@mbari.org> writes:
 >>If [W3C XML Schema can't require 1 a, 0 or 1 b, any number of c, in
 >>any order], can you offer a few words about why things were
 >>constrained in this way?
 > One reason was that there was disagreement about precedence -- that
 > is, does
 >   ( a & b? & c*)
 > mean
 >   a c b c

As in RELAX NG and computing literature (shuffle).

 > is allowed, or only
 >   a c c b

As in SGML.

 > ?
 > Another (perhaps, with hindsight, misguided) reason was to mitigate
 > the impact on parser writers.

Actually, this seems like the good reason. The mistake was probably to 
put in the crippled version of "all" because (some people apparently 
thought) it would be easy to hack into a parser.

 > And finally, there was perhaps a somewhat paternalistic (and therefore
 > again perhaps misguided) feeling that this is bad markup design - you
 > shouldn't want to do this.  It makes documents hard to read, and hard
 > to process.  Allowing something unique (e.g. your 'required_element')
 > to appear in the midst of a large collection of optional elements is
 > at best unhelpful.
 > It also seems likely to arise from a confusion between domain
 > modelling with document design -- if, as seems likely, order is not
 > significant (that is, where in the group a child occurs bears no
 > semantic weight), then good markup design is to choose an order and
 > require it.

Perhaps one's paternalistic mode is not one's most attractive. ;-}

It is a very strange idea to new document designers that if order 
doesn't matter, they should pick one anyway. I'm not at all sure the 
confusion isn't in the other direction.

And if order does matter, then the only possible markup design is to not 
choose an order. The restrictions in "all" force many designs back to 
the (a | b | ...)* pattern, losing all control over the number of 
appearances, and thereby moving the validation chore to to the 
application (or Schematron).

Bob Foster

 > Speaking only for myself,
 > ht


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS