RE: Proposal: Wildcards for WSDL 1.2 from David Orchard on 2003-07-17 (www-ws-desc@w3.org from July 2003)

From: David Orchard <dorchard@bea.com>
Date: Thu, 17 Jul 2003 08:48:01 -0700
To: "'Jonathan Marsh'" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>
Message-ID: <017201c34c7a$d7446250$620ba8c0@beasys.com>
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 11:49:17 UTC