RE: WSD WG requests to XML Schema WG

I think the problem with using xsi:type is that an older receiver that
doesn't know about the "newer" message doesn't know how to map the newer
type to the older type.  In the 2nd case, how does the nameType2 relate
to nameType1?  

If an older receiver gets the <name xsi:type="nameType2">, how does it
know that nameType2 is an extension of nameType?  Is there some way of
saying "because  the receiver knows about nameType1 and it gets an
element called name, it can ignore anything that is different between
nameType1 and nameType2?

Dave

> -----Original Message-----
> From: Matthew Fuchs [mailto:matt@westbridgetech.com]
> Sent: Thursday, February 19, 2004 6:58 PM
> To: David Orchard; w3c-xml-schema-ig@w3.org
> Cc: www-ws-desc@w3.org
> Subject: RE: WSD WG requests to XML Schema WG
> 
> 
> David,
> 
> Without going through all the schema syntax, if you just create three
> nametypes, nameType1, nameType2, and nameType3, with 2 
> extending 1 and 3
> extending 2, then you can already do:
> 
> > <name>
> > 	<first>Dave</first>
> > 	<last>Orchard</last>
> > </name>
> 
> > <name xsi:type="nameType2">
> > 	<first>Dave</first>
> > 	<last>Orchard</last>
> > 	<middle>Bryce</middle>
> > </name>
> 
> > <name xsi:type="nameType3">
> > 	<first>Dave</first>
> > 	<last>Orchard</last>
> > 	<middle>Bryce</middle>
> > 	<suffix>II</suffix>
> > </name>
> 
> You only need the xsi:type to distinguish them for validation -
> non-validating applications can ignore it.  Also this prevents:
> 
> <name>
>     <first>Dave</first>
>     <last>Orchard</last>
>     <gibberish>;laksdjf;lkadjf</gibberish>
> </name>
> 
> which wildcards don't.  Just wanted to check if that was acceptable.
> 
> Matthew
> 
> > -----Original Message-----
> > From: w3c-xml-schema-ig-request@w3.org [mailto:w3c-xml-schema-ig-
> > request@w3.org] On Behalf Of David Orchard
> > Sent: Wednesday, February 18, 2004 10:41 AM
> > To: w3c-xml-schema-ig@w3.org
> > Cc: www-ws-desc@w3.org
> > Subject: WSD WG requests to XML Schema WG
> > 
> > 
> > Dear Schema WG,
> > 
> > On behalf of the WSDL WG I'm conveying a use case for versioning, a
> > question about a solution and the intentions for Schema 1.1, and a
> > suggestion
> > to meet at the plenary F2F.
> > 
> > The WSDL WG is attempting to emerge from our Mar 4-5 FTF with a
> > Last-call ready Core specification.  We have an oustanding 
> action item
> to
> > investigate WSDL solutions to describing extensible and versionable
> > Web services.  There are 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 may be attractive to us and our customers.
> > 
> > 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.
> > 
> > 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, 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/Providing
Compatible
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 Friday, 20 February 2004 18:16:56 UTC