W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2004

Re: complexType : extension of a sequence by a choice ?

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 9 Feb 2004 10:12:11 -0500
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Cc: "'Bruno Chatel'" <bcha@chadocs.net>, "Michael Kay" <mhk@mhk.me.uk>, xmlschema-dev@w3.org
Message-ID: <OFBFF5B416.441647CA-ON85256E35.0052E5A6@lotus.com>

Henry Thompson writes:

> > I >think< we've actually had some user requests for such extension of 
> > "all", but unless Michael Kay is making such a request now (I don't 
> > he is), I can't immediately find the reference.  I think it's a nice 
> > have, but have no personal urgent need for such a new feature.  In any 

> > case the fact that it would violate the invariant quoted above doesn't 

> > particularly bother me.
> I think it should bother you, because it's fundamental
> for any versioning strategy which expects V1 software
> to process V2 instances by depending on the invariants,
> which I at least think is a very sensible approach.

I didn't say that invariants aren't important;  I am suggesting that it 
might be reasonable to have one rule that applies to sequence, and another 
that applies to "all".  In any particular context the rules are invariant, 
but we allow extension in a case where today we don't allow it at all, and 
we introduce it with its own rules.   I am suggesting that in a case where 
the base content model was "xsd:all", then the application is likely 
taking one of two approaches: 

(a) only the names of elements matter, but not their order
(b) the names and order matter, but every possible order has a meaning 
[for those who haven't noticed, the Infoset has a defined document order 
even when the schema says to validate all such orders]

Of course, to get any sort of polymorphism between base and extended 
forms, you need some predictable relationship.  In the case of sequence, 
it's that the prefix of the extended form is the base form.  I suggest 
that in the case of "all" it be that "there be a shuffle of content 
matching the extended form such that a prefix of the shuffle matches the 
base."   However you express it, I believe this is exactly what we're 
doing for attributes of an extension, and I see the rules for attributes 
as (intentionally) parallel to those for element content validated by 

Again, I'm not making a strong push that we add extension for all groups: 
I'm merely suggesting that I think we could do so in a coherent and useful 
way if there proved to be demand from users.  I believe that the rules for 
extension (and restriction) could parallel those for attributes.   Maybe 
I'm missing something.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 9 February 2004 10:51:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:18 UTC