Re: Restricting attribute use from optional to required

On 26 Aug 2009, at 02:06 , Michael Kay wrote:

>
> There's an assymetry here between attributes and child elements. For  
> the
> content model (child elements), when you restrict a type you have to  
> restate
> all the parts of the content model that you want to inherit. For  
> attributes,
> you only have to list the things that have changed - any other  
> attributes
> are inherited automatically.
>
> (No, I can't justify why it was designed that way. Like most things  
> in XSD,
> it was probably because there were too many bright people on the  
> committee
> and each of them got their way on one feature of the language.)

If memory serves, the asymmetry reflects the view (not
often challenged) that the less you have to re-specify,
the easier it is to define a restriction.  With
attributes, it's easy to devise a way to specify only
changes:  attributes are inherited unless there is
an explicit statement that they are prohibited, or
unless there is a local declaration.  For the content
model, there appears to be universal consensus that having
to repeat the content model is inconvenient, but there
don't seem to be a lot of plausible alternatives.

It would be simple to specify that the content model
in the restriction must be satisfied, and also the
content model of the base type (parallel to the rule
for restrictions by pattern in simple types), but a
significant portion of the WG feared that this would
confuse users and that it would be difficult to
implement.  Since the proposal failed to generate
consensus, it died.

If there were a convenient way to point into a content
model and say "change THAT bit there", that would be
simple, too.  But schema component designators were not
well defined at that time, and even if they had been
I am not sure users would find their use dramatically
more convenient than repeating the content model.  The
technical direction approved by the WG at that fateful
meeting was to require that the restricted content
model have essentially the same structure as the
base type's content model, so that checking that it
defined a sublanguage would be trivial.  The actual
rules got out of hand when the 1.0 editors became
ambitious about allowing alternative equivalent
formulations of a language.  Some WG members continue
to believe that it would have been best (and would
still be best) simply to take the restriction's
content model as an additional constraint that need not
restate the base type's content model constraints
(the so-called 'content-model intersection' rule).
But some WG members continue to insist that their
implementors are not smart enough to calculate
a finite state automaton which is the intersection of
two content models, and they have thus far had their
way in XSD.

The treatment of the content model and attributes could
have been made more parallel by making the handling of
attributes less convenient; would that have been better?

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Wednesday, 26 August 2009 16:05:19 UTC