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 12:51:12 -0700
To: "'Martin Gudgin'" <mgudgin@microsoft.com>, "'Jonathan Marsh'" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>
Message-ID: <01bc01c34c9c$c7951030$620ba8c0@beasys.com>
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:51:58 UTC