Lists Home |
Date Index |
Henry S. Thompson wrote:
> John Graybeal <email@example.com> 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*)
> 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).
> Speaking only for myself,