RE: WSD WG requests to XML Schema WG

David,

There are a few ways to play this, and the WG will need to discuss it.
The trailing <any> basically says _anything_ is OK, even in the base
type, so anything goes.  What's there does not need to conform to the
explicitly allowed content of _any_ subtype.  Therefore the dangling
<any> is way to permissive.

However, one can consider the fact that nameType1 is not final as an
assertion that it is "suffix open".  The xsi:type attribute says that
the content is _exactly_ the content allowed by the named type, which
includes a suffix of the defined type.  Alternatively, from your
perspective, xsi:type is a claim that:
1) the named type is a subtype of the defined type.
2) the content is prefixed by the content of the defined type.

Certainly you can verify 2, and if you know the named type, then you can
validate it's relationship with the defined type and validate the full
content.
3) if you know the named type you can validate it.
4) if you don't know the named type you can validate a prefix.

So I think "suffix open" exactly maps to what you need.  Personally I
prefer it to the dangling <any> because if you _know_ the type, no
excess content is permitted.  And it can be implemented in automata just
like the wildcard.

Matthew

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Friday, February 20, 2004 3:17 PM
> To: Matthew Fuchs; w3c-xml-schema-ig@w3.org
> Cc: www-ws-desc@w3.org
> Subject: 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