Re: Schema 1.1: xs:anyEnumeration considered?

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

Received on Tuesday, 20 March 2007 18:18:45 UTC