Re: Examples of substitution group extending WSDL.

Jonathan, others, please see my comments below.

On Wed, 2003-06-18 at 16:47, Jonathan Marsh wrote:
> 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?

Personally, I much prefer one of the things you rejected, namely
introducing a wrapper element, say wsdlsig:signature. There are several
benefits to this approach:

1) we control the schema for this element
2) optionally, the element can hold any kind of signature, i.e. its XML
Schema content would be <any namespace="##other"/> and any element
inside wsdlsig:signature could be presumed to be a signature, even
though the processor need not know the actual signature
3) optionally, the element can provide context to the signature, for
example by providing defaults to the fields inside the signature that
point to what is being signed
4) if the original schema for signatures doesn't allow extensibility
attributes, a wrapper element allows us to use wsdl:required etc.

I'm quite opposed to the idea of redefining someone else's namespace
because I believe a namespace ought to be controlled by one party. I'd
rather go without the benefits of substitution groups than try and
redefine others' schemas.

So, if we don't want the wrapper element (I think I can see why some
would feel so) and if we don't want to fiddle with others' schemas, we
lose the ability to provide functional context to the extensions and we
may lose the ability to use wsdl:required in its present attribute form,
and we may have to let go of substitution groups which were meant to
have better typing and validation on extensions. 

Note that the wrapper-element approach was taken by MS and IBM in the
SOAP Digital Signature spec: http://www.w3.org/TR/SOAP-dsig/

I think of the wrapper element as a clean, one-level-of-indirection
interface between WSDL and the extension, necessary when the
extensibility model of WSDL (subst. groups) and of the extension
(attributes like wsdl:required) don't interoperate. Granted, without
subst. groups users would have to invent fewer such wrapper elements.

Hope this makes sense,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/

Received on Thursday, 19 June 2003 09:04:22 UTC