Re: Examples of substitution group extending WSDL.

Jonathan Marsh wrote:
> 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.

One thing that needs to be added is that a WSDL document that uses this
extension will presumably have to use the xsi:schemaLocation to point to
the schema for the extension, e.g.
	<ext:extension
		xmlns:ext="http://www.example.com/extensions/mine"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.example.com/extensions/mine.xsd"/>

Otherwise I imagine that a tool that processes a WSDL document that uses
this extension and that isn't aware of it will fail to validate the
document (because the ext:extension element isn't known to belong to the
right substitution group).

> 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> 

Again I presume you'll specify a xsi:schemaLocation attribute with the
extension element. But there still seems to be a problem because
xsi:schemaLocation is just a hint, so a tool is allowed to ignore it and
use a cached copy of the *original* schema for digital signatures.
Wouldn't then this approach work only as long as the schema you're
modified hasn't been finalized/published yet?

> 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.

This is bad news.

> 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.

Given the issue with xsi:schemaLocation described earlier, I find the 
wrapper solution more acceptable than the one above, no matter how 
unaesthetical and inconvenient.

> 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?

I'm a bit torn on this issue.

On one hand, substitution groups seem to cause quite a bit of hassle, 
and I think that most extension writers/definers would be better served 
by element wildcards. In many cases, if they are reusing an existing 
schema, they wouldn't need to define any schema at all just for the 
purpose of making it embeddable in WSDL.

Also, the somewhat diminished validation capabilities that element 
wildcards afford seem to simplify things quite a bit, as WSDL 
tools/processors will be able to validate documents that use extensions 
they know nothing about without problems. Enabling tools to easily 
ignore unknown extensions was, as far as I recall, an important 
requirement for the "open content model" approach.

On the other hand, our working group, as the author of a number of new 
and substantially complex extensions (the SOAP, HTTP, ... bindings) will 
  be hurt by the more limited validation capabilities that a move to 
element wildcards would entail. In particular, schema validity for a 
document that uses, e.g., the SOAP binding will have to be complemented 
with other checks for the additional rules on which soap: extension can 
appear under which wsdl: element. This is particularly painful because 
every WSDL tool out there will have to implement these rules and won't 
be able to delegate the work to a validating XML parser.

Overall, though, my vote is to go back to element wildcards for extensions.

Roberto

Received on Thursday, 26 June 2003 08:53:14 UTC