- From: <paul.downey@bt.com>
- Date: Wed, 22 Feb 2006 17:39:14 -0000
- To: <erikj@epicor.com>, <public-xsd-databinding@w3.org>
Hi Erik! I agree that Versioning and Extensibility do often become confused, but they are closely related. One way forward is for us to anoint one or two of the Schema Versioning Use-Cases identified in this document: http://www.w3.org/XML/2005/xsd-versioning-use-cases "Object Oriented" springs to mind for this WG, though "Ignore Unknowns" is the end-game. I like the idea of only providing a patterns using '##any'. Paul -----Original Message----- From: public-xsd-databinding-request@w3.org on behalf of Erik Johnson Sent: Wed 2/22/2006 5:05 PM To: public-xsd-databinding@w3.org Subject: RE: ISSUE-20: Extension of collections I don't know if I have a great solution here, but it seems like extensibility and versioning are being muddled. By versioning, I mean having some definition of backward and/or forward compatibility between two or more schema types. The same compatibility would have to exist between the corresponding class types. Since most languages do not have specific mechanics for versioning, is it even possible to project a versioning scheme from a schema set to a language in a meaningful way? I agree that it would be very good to specify best practices for schema evolution (how to maintain backward compatibility, when to change the namespace name, etc.) and give serializer guidance about how to process/ignore "extra" nodes and when to give up trying to match the payload with class members. Also, I don't see a problem with using xs:any and mapping that to a generic type (like "object"). But the "namespace" attribute is a problem because (in most languages) there is no way to constrain a class member to be any type within a certain namespace. Should the guidance avoid using namespace attribute values other than "##any"? - Erik
Received on Wednesday, 22 February 2006 17:39:24 UTC