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

Re: Schema 1.1: xs:anyEnumeration considered?

From: David Carver <d_a_carver@yahoo.com>
Date: Tue, 20 Mar 2007 13:21:21 -0500
Message-ID: <46002621.5060506@yahoo.com>
To: Pete Cordell <petexmldev@tech-know-ware.com>
CC: David Ezell <David_E3@VERIFONE.com>, xmlschema-dev@w3.org

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


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.


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 

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

Received on Tuesday, 20 March 2007 17:20:16 UTC

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