Schema 1.1: xs:anyEnumeration considered?

[Pete Cordell]

Continuing my exploration of extensibility...

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.  Simply being able to mark a set
of enumerations as extensible seems a lot cleaner to me.  For example,
something along the lines of:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

Here the pattern restricts provides the bounds of what the anyEnumeration
can permit.  (I thought about having a pattern attribute within the
xs:anyEnumeration element, but the schema snippet above better reuses what's
defined already.)

This very much more allows the developer to ask for what they want and
doesn't require them to work around the limitations of the language with
various insider tricks.

Going further, if named wildcards were allowed (as per my earlier topic in
the week), the anyEnumeration facet could be:

            <xs:anyEnumeration socket="foo"/>

and in another schema you could have:

    <xs:plugin socket="core:foo">
        <xs:enumeration value="HIJ"/>
        <xs:enumeration value="KLMN"/>
    </xs:plugin>

>From what I understand, this sort of notation could go a long way to
addressing the problems that Jon Bosak(sp?) described that UBL had with
enumerations.

Anyway, the question is, was such a thing discussed?

Thanks,

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/
=============================================

[Bryan Rasmussen]

Whats the use of that? Wouldn't you just, in real life usage, want to say
well this can hold any 3,4 length enumeration therefore I will use the
<xs:pattern value="[a-zA-Z0-0]{3,4}"/>?

Cheers,
Bryan Rasmussen



-----Oprindelig meddelelse-----
Fra: xmlschema-dev-request@...
[mailto:xmlschema-dev-request@...]På vegne af Pete Cordell
Sendt: 16. marts 2007 16:44
Til: xmlschema-dev@...
Emne: Schema 1.1: xs:anyEnumeration considered?



Continuing my exploration of extensibility...

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.  Simply being able to mark a set
of enumerations as extensible seems a lot cleaner to me.  For example,
something along the lines of:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

Here the pattern restricts provides the bounds of what the anyEnumeration
can permit.  (I thought about having a pattern attribute within the
xs:anyEnumeration element, but the schema snippet above better reuses what's
defined already.)

This very much more allows the developer to ask for what they want and
doesn't require them to work around the limitations of the language with
various insider tricks.

Going further, if named wildcards were allowed (as per my earlier topic in
the week), the anyEnumeration facet could be:

            <xs:anyEnumeration socket="foo"/>

and in another schema you could have:

    <xs:plugin socket="core:foo">
        <xs:enumeration value="HIJ"/>
        <xs:enumeration value="KLMN"/>
    </xs:plugin>

>From what I understand, this sort of notation could go a long way to
addressing the problems that Jon Bosak(sp?) described that UBL had with
enumerations.

Anyway, the question is, was such a thing discussed?

Thanks,

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/
=============================================

[Pete Cordell]

----- Original Message From: "Bryan Rasmussen" <BRS@

> Whats the use of that? Wouldn't you just, in real life usage,
> want to say well this can hold any 3,4 length enumeration
> therefore I will use the <xs:pattern value="[a-zA-Z0-9]{3,4}"/>?

It's about the schema author specifying what they want.  Saying that
something is an enumeration that has to fit a particular pattern is very
different to saying that something is a string that has to match a pattern.

The presence of the pattern is after all a special case.  It would be quite
legitimate to do:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

which expresses a very different message to the reader than:

    <xs:simpleType name="foo" type="xs:string"/>

Also, databinding solutions are able to return the actual enumerated value
(as an  integer type constant) or declare the various strings as const/final
thus allowing for compile time checking rather than running the risk that
the user enters a typo.

Cheers,

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/
=============================================

-----Oprindelig meddelelse-----
Fra: xmlschema-dev-request@...
[mailto:xmlschema-dev-request@...]På vegne af Pete Cordell
Sendt: 16. marts 2007 16:44
Til: xmlschema-dev@...
Emne: Schema 1.1: xs:anyEnumeration considered?



Continuing my exploration of extensibility...

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.  Simply being able to mark a set
of enumerations as extensible seems a lot cleaner to me.  For example,
something along the lines of:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

Here the pattern restricts provides the bounds of what the anyEnumeration
can permit.  (I thought about having a pattern attribute within the
xs:anyEnumeration element, but the schema snippet above better reuses what's
defined already.)

This very much more allows the developer to ask for what they want and
doesn't require them to work around the limitations of the language with
various insider tricks.

Going further, if named wildcards were allowed (as per my earlier topic in
the week), the anyEnumeration facet could be:

            <xs:anyEnumeration socket="foo"/>

and in another schema you could have:

    <xs:plugin socket="core:foo">
        <xs:enumeration value="HIJ"/>
        <xs:enumeration value="KLMN"/>
    </xs:plugin>

>From what I understand, this sort of notation could go a long way to
addressing the problems that Jon Bosak(sp?) described that UBL had with
enumerations.

Anyway, the question is, was such a thing discussed?

Thanks,

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/
=============================================

[noah_mendelsohn]

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.  Not speaking formally for the WG, my impression is that the main
reason it's unlikely to happen is just schedule pressure in a relatively
small workgroup.  We have lots of users, but relatively few people
actually putting serious time into revising the specification.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Pete Cordell" <petexmldev@...>
Sent by: xmlschema-dev-request@...
03/16/2007 11:44 AM
 
        To:     <xmlschema-dev@...>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Schema 1.1: xs:anyEnumeration considered?



Continuing my exploration of extensibility...

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.  Simply being able to mark a
set
of enumerations as extensible seems a lot cleaner to me.  For example,
something along the lines of:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

Here the pattern restricts provides the bounds of what the anyEnumeration
can permit.  (I thought about having a pattern attribute within the
xs:anyEnumeration element, but the schema snippet above better reuses
what's
defined already.)

This very much more allows the developer to ask for what they want and
doesn't require them to work around the limitations of the language with
various insider tricks.

Going further, if named wildcards were allowed (as per my earlier topic in

the week), the anyEnumeration facet could be:

            <xs:anyEnumeration socket="foo"/>

and in another schema you could have:

    <xs:plugin socket="core:foo">
        <xs:enumeration value="HIJ"/>
        <xs:enumeration value="KLMN"/>
    </xs:plugin>

>From what I understand, this sort of notation could go a long way to
addressing the problems that Jon Bosak(sp?) described that UBL had with
enumerations.

Anyway, the question is, was such a thing discussed?

Thanks,

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/
=============================================

[noah_mendelsohn]

Ooops, sorry.  I didn't read your note carefully enough.  I'm not sure
anyone else has suggested the interaction with the regex.  We have had
people who want a base type with {red,blue,green} and an extension with
{red,blue,green, chartreuse}.  I think that's the essence of your
proposal, and we are aware that many users would value this.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Noah Mendelsohn
03/19/2007 04:43 PM

        To:     "Pete Cordell" <petexmldev@...>
        cc:     xmlschema-dev@...
        Subject:        Re: Schema 1.1: xs:anyEnumeration considered?


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.  Not speaking formally for the WG, my impression is that the main
reason it's unlikely to happen is just schedule pressure in a relatively
small workgroup.  We have lots of users, but relatively few people
actually putting serious time into revising the specification.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Pete Cordell" <petexmldev@...>
Sent by: xmlschema-dev-request@...
03/16/2007 11:44 AM
 
        To:     <xmlschema-dev@...>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Schema 1.1: xs:anyEnumeration considered?



Continuing my exploration of extensibility...

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.  Simply being able to mark a
set
of enumerations as extensible seems a lot cleaner to me.  For example,
something along the lines of:

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

Here the pattern restricts provides the bounds of what the anyEnumeration
can permit.  (I thought about having a pattern attribute within the
xs:anyEnumeration element, but the schema snippet above better reuses
what's
defined already.)

This very much more allows the developer to ask for what they want and
doesn't require them to work around the limitations of the language with
various insider tricks.

Going further, if named wildcards were allowed (as per my earlier topic in


the week), the anyEnumeration facet could be:

            <xs:anyEnumeration socket="foo"/>

and in another schema you could have:

    <xs:plugin socket="core:foo">
        <xs:enumeration value="HIJ"/>
        <xs:enumeration value="KLMN"/>
    </xs:plugin>

>From what I understand, this sort of notation could go a long way to
addressing the problems that Jon Bosak(sp?) described that UBL had with
enumerations.

Anyway, the question is, was such a thing discussed?

Thanks,

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/
=============================================

[David Ezell]

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

[Pete Cordell]

----- Original Message -----
From: "David Ezell" <David_E3@...>
To: <xmlschema-dev@...>
Sent: Monday, March 19, 2007 10:06 PM
Subject: Re: Schema 1.1: xs:anyEnumeration considered?

> 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




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/
=============================================

[Pete Cordell]

My apologies - This posted before I was ready (finger trouble!)

There's a fuller reply (much, much fuller!) to come!

Thanks again,

Pete.
----- Original Message -----
From: "Pete Cordell" <petexmldev@tech-...>
To: "David Ezell" <David_E3@...>; <xmlschema-dev@w3...>
Sent: Tuesday, March 20, 2007 12:00 PM
Subject: Re: Schema 1.1: xs:anyEnumeration considered?

> ----- Original Message -----
> From: "David Ezell" <David_E3@...>
> To: <xmlschema-dev@...>
> Sent: Monday, March 19, 2007 10:06 PM
> Subject: Re: Schema 1.1: xs:anyEnumeration considered?
>
>
>> 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
>
>
>
>
> 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/
> =============================================
>

[Pete Cordell]

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/
=============================================

[David Carver-3]

First, I'll state that I'm just a consumer of the spec, so I'm not a
work group member, but I do work for a B2B standards organization that
use schema extensively.
>
> And, I think only a parent could think that the union trick is not
> ugly :-)
>

Actually, it has it's good and bad points, but I don't necessarily think
it is an ugly trick, just one that is not published enough or written
about enough.   From my aspect, it takes educating my users about the
extensibility and the various ways that it can be done.

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

I deal with people that don't care how the schema is created, as long as
it doesn't affect there system and break their code.   The less they
have to deal with it the better, it's why they have our organization
create the schemas that they use.   The problem with extensibility is
that it DOES create interoperability problems, no matter how you try to
control it.   Once it is extensible, then you immediately have
interoperability problems when somebody does a one off implementation of
a schema.  Yes, you can do must understand and must ignore type logic,
but experience has shown me that people don't do this.   They bind to
the schema that they are given, and if that deviates from the industry
standard schema, they don't know or care.

Extensibility has it's place, and with enumerations, I think the way it
works now for enumerations is "good enough", not perfect but it gets the
job done.   Anything else from my experience makes more interoperability
problems not less.

Dave

[Pete Cordell]

Original Message From: "David Carver" <kingargyle@...>

Thanks for your comments Dave.

> First, I'll state that I'm just a consumer of the spec, so I'm not a work
> group member, but I do work for a B2B standards organization that use
> schema extensively.
>>
>> And, I think only a parent could think that the union trick is not ugly
>> :-)
>>
> Actually, it has it's good and bad points, but I don't necessarily think
> it is an ugly trick, just one that is not published enough or written
> about enough.   From my aspect, it takes educating my users about the
> extensibility and the various ways that it can be done.

Doesn't the fact the users need educating more about it just prove that it
is an insiders trick?

>> ...
> I deal with people that don't care how the schema is created, as long as
> it doesn't affect there system and break their code.   The less they have
> to deal with it the better, ...

I think this is the opinion of a lot of developers.  Hence the need for no
surprises.

> ...it's why they have our organization create the schemas that they use.

It may be appropriate to get specialists in to define large, industry wide
schemas, but I don't think it should be a requirement for smaller
applications of schema.  In some cases it may just be as simple as an
application's config data with a few dozen values!

One of the primary use-cases I'm interested is in using schema in emerging
protocols having extensibilitys equivalent to HTTP, SMTP and (VoIP's) SIP.
These are highly extensible protocols, developed by people (the IETF) who
are intimately familiar with extensibility issues.

> The problem with extensibility is that it DOES create interoperability
> problems, no matter how you try to control it.   Once it is extensible,
> then you immediately have interoperability problems when somebody does a
> one off implementation of a schema.

I would be interested to hear how you do your versioning.  Do you just
re-issue a new schema in a new target namespace?

> Yes, you can do must understand and must ignore type logic, but experience
> has shown me that people don't do this.   They bind to the schema that
> they are given, and if that deviates from the industry standard schema,
> they don't know or care.

I agree that, like security, people don't give versioning enough
consideration.  To be secure something needs to be designed from the
ground-up with security in mind.  Equally, to be versionable, applications
needs to be designed from the ground-up with versioning in mind.  Sadly,
only education can fix that!

> Extensibility has it's place, and with enumerations, I think the way it
> works now for enumerations is "good enough", not perfect but it gets the
> job done.   Anything else from my experience makes more interoperability
> problems not less.

Is that a case of "good enough" for you?  I certainly wouldn't force people
to make their schemas extensible (although maybe I should be saying
versionable), and it's very easy to create such schemas today.  But not all
usages of schema are the same.  What I've heard so far is, because it's not
right for me, you can't have it!  This doesn't sound reasonable to me!

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/
=============================================

[kingargyle]

>
> I would be interested to hear how you do your versioning.  Do you just
> re-issue a new schema in a new target namespace?
>
If it breaks backwards or forwards compatibility the schemas will be put
in a new namespace.  Any changes that are done that are XML Instance
level compatible, are still under the same namespace.   An example is
the following:

http://www.starstandard.org/STAR/5

Any changes that go into the schema must be backwards/forwards
compatible at the XML Instance level, not necessarily at the schema
level.  If forwards compatibility is broken, then the schema has to be
in a new namespace.

http://www.starstandard.org/STAR/6

Notice I emphasise the XML Instance level compatibility, not necessarily
the compatibility of the schema.  The reason is that we deal with
multiple implementations on the use of schema.  Some use it just for
validation, others use it just data binding and code generation.  
Because we deal with so many different ways our standards can be
implemented, we focus on XML Instance level compatibility.  Meaning the
XML must be able to validate against the specified schema.

Since we are talking about enumerations, any new enumerated values would
be considered backwards compatible.  Removing enumerated values is not
backwards compatible.   Making a field enumerated that wasn't previously
is also not backwards compatible unless you do a Union on the new
enumerations and an existing generic type like xs:string, xs:token, or
xs:normalizedString.

>> Extensibility has it's place, and with enumerations, I think the way
>> it works now for enumerations is "good enough", not perfect but it
>> gets the job done.   Anything else from my experience makes more
>> interoperability problems not less.
>
> Is that a case of "good enough" for you?  I certainly wouldn't force
> people to make their schemas extensible (although maybe I should be
> saying versionable), and it's very easy to create such schemas today.  
> But not all usages of schema are the same.  What I've heard so far is,
> because it's not right for me, you can't have it!  This doesn't sound
> reasonable to me!

I'm not saying that.  I believe refactoring should always take place,
and that the specification needs to be able to evolve to meet new
needs.  However, I also think that it isn't an issue necessarily with
the schema or the schema language itself.  I think some users need to be
willing to learn what it is and isn't good for.   Extensibility is good,
but if not designed correctly, or thought through, it can have some
devestating.   Personally, I'm not a fan of the xs:any type wildcards, I
understand their need for some cases but it makes it more complicated in
the long run for support and interoperability, too me.

I also think as high level architects we tend to try to get the perfect
solution, instead of using one that is "good enough".

Dave

[David Ezell]

Pete Cordell wrote:
>Dave Carver wrote:
>> First, I'll state that I'm just a consumer of the spec, so I'm not a
>> work group member, but I do work for a B2B standards organization that
>> use schema extensively.
>>
>>Pete Cordell wrote:
>>> And, I think only a parent could think that the union trick is not
>>> ugly
>>> :-)
>>
>> Actually, it has it's good and bad points, but I don't necessarily
>> think it is an ugly trick, just one that is not published enough or written
>> about enough.   From my aspect, it takes educating my users about the
>> extensibility and the various ways that it can be done.
>
>Doesn't the fact the users need educating more about it just prove that it is an insiders
>trick?

Well, AFAIK the "trick" originated with some folks at OASIS: they might take umbrage at being referred to as "insiders", especially where XML Schema is concerned :-).  At least OASIS is where my XML language groups learned about it.

Best regards,
David

[Pete Cordell]

Original Message From: "David Carver" <d_a_carver@...>

Thanks for this info Dave.

>> I would be interested to hear how you do your versioning.  Do you just
>> re-issue a new schema in a new target namespace?
>>
> If it breaks backwards or forwards compatibility the schemas will be put
> in a new namespace.  Any changes that are done that are XML Instance level
> compatible, are still under the same namespace.   An example is the
> following:
>
> http://www.starstandard.org/STAR/5

    (For some reason I got 404s for these links, but no worries.)

> Any changes that go into the schema must be backwards/forwards compatible
> at the XML Instance level, not necessarily at the schema level.  If
> forwards compatibility is broken, then the schema has to be in a new
> namespace.
>
> http://www.starstandard.org/STAR/6
>
> Notice I emphasise the XML Instance level compatibility, not necessarily
> the compatibility of the schema.  The reason is that we deal with multiple
> implementations on the use of schema.  Some use it just for validation,
> others use it just data binding and code generation.   Because we deal
> with so many different ways our standards can be implemented, we focus on
> XML Instance level compatibility.  Meaning the XML must be able to
> validate against the specified schema.
>
> Since we are talking about enumerations, any new enumerated values would
> be considered backwards compatible.

So what happens to say a databound implementation that has code generated
according the schema version before the enumeration was added, and it
receives an XML instance that uses an enumeration defined in the new version
of the schema?  Surely that would break the it?

> Removing enumerated values is not backwards compatible.   Making a field
> enumerated that wasn't previously is also not backwards compatible unless
> you do a Union on the new enumerations and an existing generic type like
> xs:string, xs:token, or xs:normalizedString.
>
>>> Extensibility has it's place, and with enumerations, I think the way it
>>> works now for enumerations is "good enough", not perfect but it gets the
>>> job done.   Anything else from my experience makes more interoperability
>>> problems not less.
>>
>> Is that a case of "good enough" for you?  I certainly wouldn't force
>> people to make their schemas extensible (although maybe I should be
>> saying versionable), and it's very easy to create such schemas today.
>> But not all usages of schema are the same.  What I've heard so far is,
>> because it's not right for me, you can't have it!  This doesn't sound
>> reasonable to me!
> I'm not saying that.  I believe refactoring should always take place, and
> that the specification needs to be able to evolve to meet new needs.
> However, I also think that it isn't an issue necessarily with the schema
> or the schema language itself.  I think some users need to be willing to
> learn what it is and isn't good for. ...

So if XSD isn't good for all (data oriented in my case) usages of XML, do
you think we need additional schema languages?

> ...Extensibility is good, but if not designed correctly, or thought
> through, it can have some devestating.   Personally, I'm not a fan of the
> xs:any type wildcards, I understand their need for some cases but it makes
> it more complicated in the long run for support and interoperability, too
> me.

I think we're probably at different ends of the versioning/extensbility
story!  Your looking for monolithic, slowly evolving schemas that all seem
to change in lock step.  My usage scenario is more one of modular schemas
that can be assembled together to make a whole, and may have different
schema versions from endpoint to endpoint.  In that sort of environment
versioning and extensibility are very much more are the forefront of
peoples' thoughts.  (That's not to say the people operating in that space
always get it right!  But it is an important ingredient of what they need.)

> I also think as high level architects we tend to try to get the perfect
> solution, instead of using one that is "good enough".

I agree with this sentiment.  I just don't think it's "good enough" for me!

> Dave

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/
=============================================

[Pete Cordell]

Original Message From: "David Ezell" <David_E3@...>
> Pete Cordell wrote:
> >Doesn't the fact the users need educating more about it just prove that
> it is an insiders
> >trick?
>
> Well, AFAIK the "trick" originated with some folks at OASIS: they might
> take umbrage at being referred to as "insiders", especially where XML
> Schema is concerned :-).  At least OASIS is where my XML language
> groups learned about it.

See, it took an entire standards organisation to come up with that trick.
Even the W3C couldn't think of it.  It must surely be the trickiest trick of
all :-)

And make no mistake, OASIS are insiders. They're all part of the conspiracy
:-)

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/
=============================================

[noah_mendelsohn]

Pete Cordell writes:

> One of the primary use-cases I'm interested is in using schema in
emerging
> protocols having extensibilitys equivalent to HTTP, SMTP and (VoIP's)
SIP.
> These are highly extensible protocols, developed by people (the IETF)
who
> are intimately familiar with extensibility issues.

One of the things that became clear early to those of us who are trying to
make progress on versioning and extensibility is that there are many, many
use cases.  They differ in many dimensions, including the ones you point
to.  While I can't say that we necessarily got a representative set of
even the most important ones, we did try.  If you're interested, there are
a couple of Web pages that are publicly accessible.  These include:

* XML Schema Working Group Versioning Resources (see [1]) -  This is
basically a page with pointers to some other interesting pages, including:

* XML Schema Versioning Use Cases (see [2])

* We then tried to integrate a look at quite a range of mechanisms that
had been proposed and how they would or wouldn't address at least some of
the use cases (see [3])

* Also referenced is a very early "thought piece" that I wrote for the
group in 2004.  It certainly did not at the time and does not now
represent any sort of consensus of the workgroup, but it was among the
analyses that was considered (see [4]).  BTW: it's labeled as a "rough
draft", but as I recall no less rough draft was ever circulated.
Interestingly, I think the mechanisms proposed for XML Schema 1.1 do fit
moderately well with what I suggested as desiderata in this note.  That's
not particularly because my note was adopted as the basis for our work (it
wasn't), but I do note that where we landed is in some sense not too far
from where I was hoping we would when we got serious about this 3 years
ago.  FWIW: I would prefer to change the terminology a bit.  The paper
uses the terms language and vocabulary more or less interchangeably, which
I now think is unfortunate.  I'd prefer to think of a language as
(roughly) a class of documents conforming to some particular
specification.  I'd prefer to use the word vocabulary for things like tag
names, and perhaps enumeration values, which are used in building those
documents.

Noah


[1] http://www.w3.org/2005/05/xsd-versioning-resources.html
[2] http://www.w3.org/XML/2005/xsd-versioning-use-cases/ 
[3] http://www.w3.org/XML/2004/02/xsdv.html
[4]
http://lists.w3.org/Archives/Public/www-tag/2004Aug/att-0010/NRMVersioningProposal.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[brycenesbitt]

How about something akin to "javax".  The ability to insert an extra attribute to a non-conforming element that says "this is extended beyond the schema".  Then you'd still catch mistakes in a standard type (e.g. "runtal" when "rental" was meant), but still allow true extensions (e.g. "leasing").  

I like the idea of providing an enumeration, even in cases where that's just a serving suggestion or starting point.

Pete Cordell wrote:

One thing I often see are sets of enumerations that are not extensible....

    <xs:simpleType name="foo">
        <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
            <xs:enumeration value="ABC"/>
            <xs:enumeration value="DEFG"/>
            <xs:anyEnumeration/>  <!-- New -->
        </xs:restriction>
    </xs:simpleType>

[Pete Cordell]

I'm not familiar with this.  Do you have a URL I can look at?

Thanks,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML Schema to C++ data binding visit
 http://www.tech-know-ware.com/lmx/
 http://www.codalogic.com/lmx/
=============================================

----- Original Message -----
From: "brycenesbitt" <bryce1@...>
To: <xmlschema-dev@...>
Sent: Wednesday, May 02, 2007 12:59 AM
Subject: Re: Schema 1.1: xs:anyEnumeration considered?

>
>
> How about something akin to "javax".  The ability to insert an extra
> attribute to a non-conforming element that says "this is extended beyond
> the
> schema".  Then you'd still catch mistakes in a standard type (e.g.
> "runtal"
> when "rental" was meant), but still allow true extensions (e.g.
> "leasing").
>
> I like the idea of providing an enumeration, even in cases where that's
> just
> a serving suggestion or starting point.
>
>
> Pete Cordell wrote:
>>
>>
>> One thing I often see are sets of enumerations that are not
>> extensible....
>>
>>     <xs:simpleType name="foo">
>>         <xs:restriction base="xs:string">
>>             <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
>>             <xs:enumeration value="ABC"/>
>>             <xs:enumeration value="DEFG"/>
>>             <xs:anyEnumeration/>  <!-- New -->
>>         </xs:restriction>
>>     </xs:simpleType>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Schema-1.1%3A-xs%3AanyEnumeration-considered--tf3415265.html#a10278076
> Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.
>
>
>

[Chuck Herrick]

Here is one URL:
  http://www.google.com/search?hl=en&q=javax&btnG=Google+Search

>
> I'm not familiar with this.  Do you have a URL I can look at?
>
> Thanks,
>
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware Ltd
> for XML Schema to C++ data binding visit
>  http://www.tech-know-ware.com/lmx/
>  http://www.codalogic.com/lmx/
> =============================================
>
> ----- Original Message -----
> From: "brycenesbitt" <bryce1@...>
> To: <xmlschema-dev@...>
> Sent: Wednesday, May 02, 2007 12:59 AM
> Subject: Re: Schema 1.1: xs:anyEnumeration considered?
>
>
> >
> >
> > How about something akin to "javax".  The ability to insert an
> extra
> > attribute to a non-conforming element that says "this is extended
> beyond
> > the
> > schema".  Then you'd still catch mistakes in a standard type
> (e.g.
> > "runtal"
> > when "rental" was meant), but still allow true extensions (e.g.
> > "leasing").
> >
> > I like the idea of providing an enumeration, even in cases where
> that's
> > just
> > a serving suggestion or starting point.
> >
> >
> > Pete Cordell wrote:
> >>
> >>
> >> One thing I often see are sets of enumerations that are not
> >> extensible....
> >>
> >>     <xs:simpleType name="foo">
> >>         <xs:restriction base="xs:string">
> >>             <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
> >>             <xs:enumeration value="ABC"/>
> >>             <xs:enumeration value="DEFG"/>
> >>             <xs:anyEnumeration/>  <!-- New -->
> >>         </xs:restriction>
> >>     </xs:simpleType>
> >>
> >>
> >
> > --
> > View this message in context:
> >
>

http://www.nabble.com/Schema-1.1%3A-xs%3AanyEnumeration-considered--tf3415265.html#a10278076
> > Sent from the w3.org - xmlschema-dev mailing list archive at
> Nabble.com.
> >
> >
> >
>
>
>
>


--
Chuck Herrick
mailto:cherrick@...
512 289 0926 (cell)
830 839 4437 (home)

[Pete Cordell]

Gee, thanks.  Believe it or not I had already tried that, but it didn't
actually give me any additional insight into what the OP was suggesting.
About as useful as suggesting:

http://www.google.com/search?hl=en&q=computer+science&btnG=Google+Search

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML Schema to C++ data binding visit
 http://www.tech-know-ware.com/lmx/
 http://www.codalogic.com/lmx/
=============================================

----- Original Message -----
From: "Chuck Herrick" <cherrick@...>
To: "Pete Cordell" <petexmldev@...>
Cc: "brycenesbitt" <bryce1@...>; <xmlschema-dev@...>
Sent: Wednesday, May 02, 2007 3:29 PM
Subject: Re: Schema 1.1: xs:anyEnumeration considered?

>
> Here is one URL:
>  http://www.google.com/search?hl=en&q=javax&btnG=Google+Search
>
>>
>> I'm not familiar with this.  Do you have a URL I can look at?
>>
>> Thanks,
>>
>> Pete.
>> --
>> =============================================
>> Pete Cordell
>> Tech-Know-Ware Ltd
>> for XML Schema to C++ data binding visit
>>  http://www.tech-know-ware.com/lmx/
>>  http://www.codalogic.com/lmx/
>> =============================================
>>
>> ----- Original Message -----
>> From: "brycenesbitt" <bryce1@...>
>> To: <xmlschema-dev@...>
>> Sent: Wednesday, May 02, 2007 12:59 AM
>> Subject: Re: Schema 1.1: xs:anyEnumeration considered?
>>
>>
>> >
>> >
>> > How about something akin to "javax".  The ability to insert an
>> extra
>> > attribute to a non-conforming element that says "this is extended
>> beyond
>> > the
>> > schema".  Then you'd still catch mistakes in a standard type
>> (e.g.
>> > "runtal"
>> > when "rental" was meant), but still allow true extensions (e.g.
>> > "leasing").
>> >
>> > I like the idea of providing an enumeration, even in cases where
>> that's
>> > just
>> > a serving suggestion or starting point.
>> >
>> >
>> > Pete Cordell wrote:
>> >>
>> >>
>> >> One thing I often see are sets of enumerations that are not
>> >> extensible....
>> >>
>> >>     <xs:simpleType name="foo">
>> >>         <xs:restriction base="xs:string">
>> >>             <xs:pattern value="[a-zA-Z0-0]{3,4}"/>
>> >>             <xs:enumeration value="ABC"/>
>> >>             <xs:enumeration value="DEFG"/>
>> >>             <xs:anyEnumeration/>  <!-- New -->
>> >>         </xs:restriction>
>> >>     </xs:simpleType>
>> >>
>> >>
>> >
>> > --
>> > View this message in context:
>> >
>>
> http://www.nabble.com/Schema-1.1%3A-xs%3AanyEnumeration-considered--tf3415265.html#a10278076
>> > Sent from the w3.org - xmlschema-dev mailing list archive at
>> Nabble.com.
>> >
>> >
>> >
>>
>>
>>
>>
>
>
> --
> Chuck Herrick
> mailto:cherrick@...
> 512 289 0926 (cell)
> 830 839 4437 (home)
>
>