RE: Proposal: Wildcards for WSDL 1.2

Are you suggesting that the next ( for some definition of next ) version
of WSDL use the same namespace as this one?

Gudge

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: 17 July 2003 12:51
> To: Martin Gudgin; Jonathan Marsh; www-ws-desc@w3.org
> Subject: RE: Proposal: Wildcards for WSDL 1.2
> 
> The point would be to allow extension in the WSDL namespace 
> to allow for forwards and backwards compatible changes.  Why 
> not allow for compatible changes given how simple this 
> proposal is?  If the solution allowing for compatible changes 
> were complicated, I could potentially understand a simplicity 
> argument against it.  But the solution is fairly simple, so I 
> advocate leaving the loose coupling option open.
> 
> Dave
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Martin Gudgin
> > Sent: Thursday, July 17, 2003 12:21 PM
> > To: David Orchard; Jonathan Marsh; www-ws-desc@w3.org
> > Subject: 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:55:34 UTC