RE: Proposal: Wildcards for WSDL 1.2

We decided a week or two ago to use an open content model instead of
substitution groups, now we're just polishing off that item by deciding
what the default validation mode should be.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of David Orchard
> Sent: Wednesday, July 16, 2003 1:34 PM
> To: www-ws-desc@w3.org
> Subject: Proposal: Wildcards for WSDL 1.2
> 
> I'd like to propose the use of wildcards in WSDL 1.2 rather than
> substitution groups.  My understanding of the rationale for
substitution
> groups is at least two-fold: Problems with determinism, and desire for
> validation.  On the first reason, there are some schema techniques
that
> can be used that allow full extensibility and backwards/forwards
> compatible changes.  The validation requirement I've addressed
separately.
> 
> The core technique is to make the extensions in the same namespace
into an
> optional extension element.  The documented type then becomes:
> 
>   <xs:complexType name="ExtensibleDocumented" abstract="true"
> mixed="false">
>   <xs:annotation>
>   <xs:documentation>This type is extended by component types to allow
> attributes from other namespaces to be added.</xs:documentation>
>   </xs:annotation>
>   <xs:complexContent>
>   <xs:extension base="wsdl:Documented">
>   <xs:anyAttribute namespace="##any" processContents="lax" />
>   <xs:element name="Extension" type="wsdl:ExtensionType" minOccurs="0"
> maxOccurs="1"/>
>   <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"
> namespace="##other"/>
>   </xs:extension>
>   </xs:complexContent>
>   </xs:complexType>
> 
>   <xs:complexType name="ExtensionType">
>    <xs:sequence>
>       <xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"
> namespace="##targetnamespace"/>
>    </xs:sequence>
>    <xs:anyAttribute/>
>   </xs:complexType>
> 
> This might not quite be it, because the wsdl:required attribute needs
to
> be applicable to same namespace and different namespace extensions.
> 
> This resolves the determinism problems with namespace="##any" which
can't
> follow elements with minOccurs!=maxOccurs.  It makes the tree a bit
more
> complicated when forward compatible schema changes happen in the same
> namespace, as the extensionType needs to be refined for each
extension.
> As in, adding a <wsdl:foo/> in a forwards compatible way means that
the
> instance looks like <Extension><foo/></Extension>.  But this does
allow
> forwards and backwards compatible changes.
> 
> What do y'all think?
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Jonathan Marsh
> > Sent: Wednesday, June 18, 2003 7:48 AM
> > To: www-ws-desc@w3.org
> > Subject: Examples of substitution group extending WSDL.
> >
> >
> >
> > Results of my tinkering below.
> >
> > First, I created an instance with a brand new extension to see how a
> > fresh extension schema would work.
> >
> >   <definitions xmlns="http://www.w3.org/@@@@/@@/wsdl"
> >                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >                xmlns:my="http://www.example.com/extensions/mine"
> >
> > xsi:schemaLocation="http://www.example.com/extensions/mine
> > extension.xsd
> > http://www.w3.org/@@@@/@@/wsdl wsdl.xsd"
> >                targetNamespace="http://example.com/jonathan/test">
> >     <documentation>This file tests validation of an extended WSDL
> > document</documentation>
> >     <my:extension>Jonathan Marsh</my:extension>
> >   </definitions>
> >
> > I described this extension with a schema, and inserted it into the
> > globalExt substitution group (which allows the extension to appear
at
> > the top level, and almost anywhere else, within WSDL).
> >
> >   <xs:schema
targetNamespace="http://www.example.com/extensions/mine"
> >              xmlns:wsdl="http://www.w3.org/@@@@/@@/wsdl"
> >              xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >              elementFormDefault="qualified">
> >     <xs:import namespace="http://www.w3.org/@@@@/@@/wsdl"
> >                schemaLocation="wsdl.xsd"/>
> >     <xs:element name="extension" type="xs:string"
> >                 substitutionGroup="wsdl:globalExt"/>
> >   </xs:schema>
> >
> > Notes:
> > 1) The extension schema imports the wsdl schema for the purpose of
> >    allowing the substitution group to be specified.
> > 2) The validator needs to associate both the extension schema and
> >    the WSDL schema.  In this case I used the xsi:schemaLocation
> >    mechanism.
> >
> >
> > Next I took an existing vocabulary (DSig) and tried to embed it in
the
> > WSDL.
> >
> >   <definitions xmlns="http://www.w3.org/@@@@/@@/wsdl"
> >                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >                xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> >
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
> > wsdl+dsig.xsd http://www.w3.org/@@@@/@@/wsdl wsdl.xsd"
> >                targetNamespace="http://example.com/jonathan/test">
> >     <documentation>This file tests validation of an extended WSDL
> > document</documentation>
> >     <ds:Signature>
> >       <ds:SignedInfo>
> >         <ds:CanonicalizationMethod
> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> >         <ds:SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
> >         <ds:Reference
> > URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
> >           <ds:Transforms>
> >             <ds:Transform
> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> >           </ds:Transforms>
> >           <ds:DigestMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >
> > <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
> >         </ds:Reference>
> >       </ds:SignedInfo>
> >       <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
> >     </ds:Signature>
> >   </definitions>
> >
> > In order to validate this, I had to modify the DSig schema
> > (wsdl+dsig.xsd) in three ways:
> > 1) Add an appropriate substitutionGroup attribute, with the value of
a
> > WSDL extension group QName.
> > 2) Declare WSDL namespace prefix so the QName is valid.
> > 3) Add an import of the wsdl schema so the QName reference is
> > complete.
> >
> > (new lines marked with "|")
> >
> >   <schema targetNamespace="http://www.w3.org/2000/09/xmldsig#"
> >           ...>
> > |   <import namespace="http://www.w3.org/@@@@/@@/wsdl"
> > |           schemaLocation="wsdl.xsd"/>
> >     <element name="Signature" type="ds:SignatureType"
> > |            substitutionGroup="wsdl:globalExt"
> > |            xmlns:wsdl="http://www.w3.org/@@@@/@@/wsdl"/>
> >     ...
> >   </schema>
> >
> > Then I attempted the holy grail, a simple wrapper schema that
> > would have
> > the effect of the schema above, while importing the DSig
> > schema without
> > modification.  I failed in this because:
> > - Element declarations in an imported schema cannot be overridden.
> > - Redefine does not work on element declarations.
> > - There is no other way to add elements to a substitution group.
> >
> > I rejected modifications to the instance document that would enable
a
> > wrapper schema:
> > - Changing the namespace of the top level element.
> > - Introducing a wrapper element.
> >
> > My conclusion is that the cleanest way to enable this scenario was
> > copying and modifying the DSig schema with the simple additions
found
> > above.  I also note that this would be necessary to allow
> > wsdl:required
> > attributes to appear on ds:Signature elements.
> >
> > Do we find this limitation acceptable?  Does this limitation
outweigh
> > the benefits of our substitution group extensibility mechanism?
> >
> >
> >

Received on Thursday, 17 July 2003 10:56:43 UTC