W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

RE: Revised extensibility proposal

From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
Date: Wed, 22 May 2002 13:49:22 -0400
Message-ID: <849C1D32E4C7924F854D8A0356C72A9E042F724E@usilms08.ca.com>
To: Jonathan Marsh <jmarsh@microsoft.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>
Cc: www-ws-desc@w3.org
1. It's up to the WSDL processor to accept or ignore just about anything. We cannot mandate the implementation of the processor anyways, no matter what we say in a spec. That is why I didn't see a difference in making it one way or the other. Also I believe the extension declaration is basically optional even in the Roberto's proposal.
It is a good practice though to declare extensions beforehand, and that should get into the spec wordings. It sort of sets one's mind in a right direction when designing and using extensions. It helps both the designer and the processor in setting up proper context.
Certain extensions may as well be assumed default by explicitly saying that in a spec.

2. Why not have an indication of what's required and what's not when declaring an extension? The logic is simple: a globally required flag that is set when declaring an extension (default = required) and a locally required tag that *may* be set on any extension element (default = optional). Locally required tag, if set explicitly, overrides globally required tag. That way I can have any combinations I like when defining a WSDL doc with extensions. That is why I thought your cases are covered too.
It would have been quite frivolous to leave this at the WSDL processor peril...
It avoids a situation when a WSDL processor tells you can use a service and when you actually use it, it fails right away because there were some additional restrictions/requirements otherwise already known.

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Wednesday, May 22, 2002 12:38 PM
To: Sedukhin, Igor; Jean-Jacques Moreau
Cc: www-ws-desc@w3.org
Subject: RE: Revised extensibility proposal

Maybe I've misunderstood Roberto's proposal, but I think there is at least one difference in behavior.  In Roberto's proposal, use of an attribute or element in a non-wsdl namespace, but not declared as an extension, results in an error (or "WSDL-not-understood" behavior of some kind).  In mine, it may safely be ignored.

There are syntactic differences too.  My proposal doesn't have the wsdl:required attribute, or the required attribute on <wsdl:extension>.

> -----Original Message-----
> From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
> Sent: Wednesday, May 22, 2002 9:20 AM
> To: Jean-Jacques Moreau; Jonathan Marsh
> Cc: www-ws-desc@w3.org
> Subject: RE: Revised extensibility proposal
> The proposals do not contradict each other. What is there to choose?
> for both then?
> -- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> -----Original Message-----
> From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
> Sent: Wednesday, May 22, 2002 12:08 PM
> To: Jonathan Marsh
> Cc: www-ws-desc@w3.org
> Subject: Re: Revised extensibility proposal
> +1 for Jonathan's proposal.
> Jonathan Marsh wrote:
> > I still don't see why a simpler proposal won't work:
> >
> > 1) Open the content model to elements and attributes in other 
> > namespaces.
> > 2) Mark required extensions with a <wsdl:extension namespace="..."/> 
> > element.
> > 3) An interpreter of the WSDL document, encountering an element or 
> > attribute marked as a required extension but not recognizing the 
> > namespace of that element, must interpret the entire WSDL document
> > "not understood".
> > 4) Certain elements can accept "architected extensions" which means 
> > they don't have to be declared using the extension mechanism.  These 
> > are not really extensions at all, just boundaries between embedded 
> > namespaces.
Received on Wednesday, 22 May 2002 13:49:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC