W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2007

Re: Schema 1.1: xs:anyEnumeration considered?

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Tue, 20 Mar 2007 14:14:15 -0000
Message-ID: <00fb01c76afa$14398270$c900a8c0@Codalogic>
To: "David Ezell" <David_E3@VERIFONE.com>, <xmlschema-dev@w3.org>

Original Message From: "David Ezell" <David_E3@...>

>Pete Cordell wrote:
>> .. snipped...
> 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. :-)

Many thanks for your comments David.  It's very enlightening being able to
get an insight into the issues the WG is and has considered.

> 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.

I understand your concerns about the problems of having extensibility like
this.  However, I think the only thing worse than having too much
extensibility is not having enough extensibility!

I'm afraid I'm not fully familiar with the problems you encountered, but I
imagine that the problems occurred because people were creating their own
enumerations and then using them with partners with whom they
didn't have suitable relationships.

To me this is not fundamentally a problem with the XML language that was
developed, but a problem with the policy in the way the language is used.
Hopefully, after reigning in peoples' enthusiasm, interoperability could
again be achieved.  For example, in the IETF some protocols have very
specific rules about what codes can go into extensibility points, in some
cases requiring them to be defined in working group approved RFCs.  As part
of this an appropriate scheme for handling the 'extension unknown' case
would typically be documented.

> 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.

I think there are a number of ways in which extensibility like this can be
handled.  I don't think that there is a one-size-fits-all method.  My
concern would be that if the WG came up with a "truly extensible
enumeration" they would come up with a cumbersome scheme that rarely met
peoples' requirements.  For example, for some people an unknown enumeration
can simply be ignored.  Some people might want an unknown enumeration to
cause a request failure and then they'd re-try with a downgraded request.
Some might try an HTTP like OPTIONS request first to assess what is
supported.  And some might even detect the failure and have humans get
involved in uploading new tables of something (or phone up the sender and
tell them not to do it again!).  And this is just in the protocol world.  In
many cases the approach taken may differ for each enumeration in a schema.

Hence, without seeing the details of what's proposed, I think providing the
building blocks for such schemes is what's required, not presenting users
with a single, most likely complex, 'safe' solution.

And, I think only a parent could think that the union trick is not ugly :-)

But what I don't like about the union trick is that I've never seen anyone
use it the first time they tried to make an extensible enumeration.  Schema
is a beast to learn.  This problem is compounded by the fact that for many
developers only a tiny fraction of their time will involve developing
schemas.  Hence they won't have the miles and miles of experience that they
have in the other languages they use day in-day out.  I think the WG should
recognise this by not requiring developers to use secret handshakes and
incantations to avoid ending up hitting brick walls!  My concern is that, by
being the elite in schema develop (and probably among the elite of
developers in general), the WG members don't fully appreciate these
difficulties that lesser developers have with schema, and so dismiss them as
un-important.

Apologies if that sounds a bit ranty.  It's not intended to be!

Thanks again,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================
Received on Tuesday, 20 March 2007 14:15:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:12 UTC