Here's a cut.
(Maybe link to or from this line from 2.2.1, part 1:
"""This specification does not define the behavior of a WSDL 2.0
document that uses multiple schema languages for describing type system
components simultaneously.""")
----------------
*Issues facing multiple schema languages/type systems*
Without the use of an extension, a WSDL document can only use a single
type system, XML Schema. If extensions are defined to support
alternative schema languages or non-XML type systems, then issues
regarding the *mixing* of type systems in a single document arise. Part
1 does *not* define the behavior of mixed type system documents, so it
is incumbent on extension authors to do so.
For example, suppose a WSDL author used a extension supporting Relax NG
along side the built in support for XML Schema. Further suppose that
there is an element component which has a definition in both the
referenced XML Schema and Relax NG schema. There are several
possibilities for interpreting such a document:
* Multiple definitions in distinct type systems is always an error
* Multiple definitions must be in some sense equivalent, for example,
if XML Schema type and an Relax NG production validate exactly the same
set of Infoset fragments, otherwise, an error
* Multiple definitions are legal, and are interpreted as a union type
constraint
The first interpretation seems most in spirit with WSDL.
The last interpretation suggests a further general possibility: being
able to define a union type (or other compound type) that spans
distinct type systems (and, to generalize, where the unioned types had
distinct QName identifiers). The Data Access Working Group had a use
case wherein their return message could either be in RDF/XML, which
cannot have an interesting XML Schema but does have an interesting
Relax NG schema, and their other results format, which they'd prefer to
specify with an XML Schema. This example is little artificial, as the
Data Access Working Group could easily describe the entire results
format in Relax NG.
Cheers,
Bijan.