Altova Mailing List Archives

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

From: Bob Foster <bob@------.--->
To: "Henry S. Thompson" <ht@---.--.--.-->
Date: 2/19/2005 5:00:00 AM
Henry S. Thompson wrote:
 > John Graybeal <graybeal@m...> 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


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.