RE: Proposal: Wildcards for WSDL 1.2

I don't believe we have any wildcards that specify ##targetNamespace,
nor do we need any. Extensions are all going to be in a namespace other
than the WSDL namespace. So we only need ##other.

Gudge

> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of David Orchard
> Sent: 17 July 2003 08:48
> To: Jonathan Marsh; www-ws-desc@w3.org
> Subject: RE: Proposal: Wildcards for WSDL 1.2
> 
> So can the group interpret this as a friendly amendment for a 
> refinement on how to do the open content model?  In 
> particular, the separation of ##other and ##targetnamespace 
> content models.
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> > Sent: Thursday, July 17, 2003 7:56 AM
> > To: David Orchard; www-ws-desc@w3.org
> > Subject: 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 15:21:21 UTC