RE: WSDL WG request for adding multiple version extensibility into Schema 1.1

This looks good, but I would like to add a sense of urgency to it by
explaining a little of our current state, something like:

"The WSDL WG is attempting to emerge from our Mar 4-5 FTF with a
Last-call ready the Core specification, and is several avenues toward a
solution which include exploring fixes directly to Schema to allow
evolution of message structure, ways we might layer on top of Schema to
provide these capabilities, and encouraging use of alternative Schema
languages.  A solution available in XML Schema 1.1 would be attractive.
Although we are meeting at the FTF, we are not meeting concurrently with
your group; but perhaps there is an opportunity for a few Schema WG
members to join us on Thursday to explain our needs and explore
solutions."

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of David Orchard
> Sent: Friday, February 13, 2004 12:06 PM
> To: www-ws-desc@w3.org 
> Subject: WSDL WG request for adding multiple version extensibility
into
> Schema 1.1
> 
> 
> Hi all,
> 
> Here's proposed text to send to the XML Schema WG on issue of
versioning.
> Please let me know when you can.  I'd prefer to send this before the
wsd
> wg
> telcon on thursday.
> 
> Dear Schema WG,
> 
> On behalf of the WSDL WG I'm conveying a use case for versioning and
> question about a solution and the intentions for Schema 1.1.
> 
> In discussions on Providing Compatible Schema Evolution [1], the broad
> question of extensibility and versioning as a whole was examined. And
> there
> are tricky problems and difficult choices for solutions. Another
important
> question to ask is what is the minimum necessary for success in
> versioning?
> If one assumes that we do not need to insert elements in arbitrary
places,
> just at the end, and retaining compatibility, then there may be a
simpler
> solution that XML Schema 1.1 could do. Let us take a simple name
example
> through two iterations. The first iteration adds an optional "middle"
name
> at the end of the name. The second option adds an optional "suffix" at
the
> end of the extended name.  This looks like:
> 
> <name>
> 	<first>Dave</first>
> 	<last>Orchard</last>
> </name>
> 
> <name>
> 	<first>Dave</first>
> 	<last>Orchard</last>
> 	<middle>Bryce</middle>
> </name>
> 
> <name>
> 	<first>Dave</first>
> 	<last>Orchard</last>
> 	<middle>Bryce</middle>
> 	<suffix>II</suffix>
> </name>
> We want these 3 of these documents to be valid against the 3 schemas.
It
> seems that the simplest change would be to have a "low priority"
wildcard
> as
> mentioned in previous discussions. The schemas using this would be
> something
> like:
> 
> <xs:complexType name="nameType">
> 	<xs:sequence>
> 		<xs:element name="first" type="xs:string" />
> 		<xs:element name="last" type="xs:string" minOccurs="0"/>
> 		<xs:any namespace="##any"/>
> 	</xs:sequence>
> </xs:complexType>
> 
> <xs:complexType name="nameType">
> 	<xs:sequence>
> 		<xs:element name="first" type="xs:string" />
> 		<xs:element name="last" type="xs:string" minOccurs="0"/>
> 		<xs:element name="middle" type="xs:string"
minOccurs="0"/>
> 		<xs:any namespace="##any"/>
> 	</xs:sequence>
> </xs:complexType>
> 
> <xs:complexType name="nameType">
> 	<xs:sequence>
> 		<xs:element name="first" type="xs:string" />
> 		<xs:element name="last" type="xs:string" minOccurs="0"/>
> 		<xs:element name="middle" type="xs:string"
minOccurs="0"/>
> 		<xs:element name="suffix" type="xs:string"
minOccurs="0"/>
> 		<xs:any namespace="##any"/>
> 	</xs:sequence>
> </xs:complexType>
> 
> It seems that a low priority wildcard is sufficient to enable an
explicit
> extensibility point that allows backwards and forwards compatible
> evolution
> through multiple versions with extension at the end of the type
definition
> and extension in the same namespace. This isn't the fullest solution,
as
> it
> does not allow for default extensibility, nor extensibility in between
> elements. But this appears significantly improved over current
> capabilities.
> 
> I'm not able to track the intricacies of the discussion, but it
appears
> that
> the Schema group is talking about this in the context of RQ-135, with
a
> proposal at [2], another proposal about 2nd class wildcards at [3],
and a
> fair amount of follow on discussion.  Again, I can't follow through
the
> intricacies of the discussion of the ilk of subsumption of lexical
spaces
> versus value spaces for redefinition, and why a validator needs to
look up
> the tree for subsumption.
> 
> We are interested in determining whether the Schema WG sees: this use
case
> as important for Schema 1.1, whether this use case will be solved in
> Schema
> 1.1, if low priority wildcards are a solution to this problem, and if
> low-priority wildcards will be the Schema 1.1 solution.
> 
> On behalf of the WSDL WG,
> Dave Orchard
> 
> [1]
>
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatible
Sc
> he
> maEvolution.html
> [2] http://lists.w3.org/Archives/Member/w3c-xml-schema-
> ig/2004Feb/0028.html
> [3] http://lists.w3.org/Archives/Member/w3c-xml-schema-
> ig/2004Feb/0035.html

Received on Monday, 16 February 2004 12:55:21 UTC