Re: Schema 1.1: xs:anyEnumeration considered?

In response to Pete Cordele, Noah Mendelsohn wrote:
>I'm not optimistic that we'll get to do anything about this in Schema 1.1, but it's 
>not a new requirement.  I believe it's been raised by a number of people over the years, 
>and the WG generally understands that the need is there.
>
>Pete Cordell wrote:
>>One thing I often see are sets of enumerations that are not extensible.  I 
>>know that there is a trick with xs:union that you can do with this, but 
>>many people don't know about it and it is ugly. One thing I often see are sets of 
>>enumerations that are not extensible.  I know that there is a trick with xs:union 
>>that you can do with this, but many people don't know about it and it is ugly. 

Like Noah, I'm not speaking for the WG.  However, I am a WG member with a keen interest in extensibility, so I feel like I should weigh in here.  (Let me start by saying that as a WG member I'm very pleased to have get this kind of feedback.  Don't let the fact that I disagree in this particular case make anyone think I'm unappreciative. :-)

As a WG member, I consciously decided >not< to lobby for this feature, which I'll call "simplistic enumeration extension", or SEE from now on.  In terms of what we think of extensibility, it runs contrary to other mechanisms in that it allows information that's totally unexpected to appear in a field.  In other extensibility mechanisms that have been proposed (like our enhanced wildcard formulations or even type derivation) a naïve application will at least have >some< familiar data to work with even if the unexpected appears.  

My experience at NACS (National Association of Convenience Stores) as chair of a working group working on XML languages is as follows:

In the previous version of our languages, our members insisted on extensibility of enumerations, so we used the "trick" with xs:union you mentioned (it's really not all that ugly :-) throughout our language, litterally dozens of enumerations.  Our overwhelming experience is that such extensions break interoperability in ways that other kinds of extension don't, so we're removing the construct entirely from the next version of our languages.

Therefore, as a WG member I've not lobbied for SEE.  To be fair, I did at one point lobby for a truly extensible enumeration (i.e. with a predefined way to identify a well-known fallback value to that naïve applications can continue) but the WG has not had time to consider this kind of mechanism.  I'd actually advise against SEE because 1) it's misleading in terms of interoperability, and 2) the "ugly" alternative really isn't that bad.

My $0.02.

Best regards,
David

Received on Monday, 19 March 2007 22:05:17 UTC