RE: Revised extensibility proposal

Jonathan,

Your changes eliminate these cases

Roberto notes: "One case that my proposal covers is having an extension vocabulary being optional but being able to mark one particular extension element taken from that very same vocabulary as required."

And another one would be the reverse, i.e. when an extension is required, but one of the elements is optional (like an annotation within an extension).

Would you bet that none of these would ever be needed by anyone?
If the content model is being open, it has to be comprehensive.

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



-----Original Message-----
From: Roberto Chinnici [mailto:roberto.chinnici@sun.com] 
Sent: Wednesday, May 22, 2002 7:59 PM
To: Jonathan Marsh
Cc: www-ws-desc@w3.org
Subject: Re: Revised extensibility proposal


Jonathan Marsh wrote:

> Personally, the whole thing seems needlessly complex, with Declared 
> Extensions, Undeclared Extensions, Declared Required Extensions, 
> Undeclared Required Extensions, and two syntaxes for indicating 
> Required that will interact in strange ways.  <my:ext 
> wsdl:required="false"/> may in fact be a required extension - you have 
> to look at the prologue to tell.
>
> 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 as 
> "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.

One case that my proposal covers is having an extension vocabulary being optional but being able to mark one particular extension element taken from that very same vocabulary as required.

Moreover, although my previous proposal used architected extensions, I like the new one (in which there are no architected extensions at all) much better. By not singling out certain extensibility points as special, it seems to better allow for future language evolution.

> Note this also solves the annotation problem.

That's a separate subject, really!  :-)

The extensibility proposal solves the annotation problem only if you think that annotations are extensions. I still see a value in having a special placeholder for metadata, separate from language extensions.

> What is the purpose of marking an optional extension?  What the 
> extension does (optional or required) is certainly the business of the 
> spec for that extension.  The more kinds of extension we introduce, 
> the more we tread into processing models and stray from a declarative 
> language.

I agree with you that what an extension does is none of our business, but a processor that doesn't recognize an extension cannot possibly have any clues about what it does. So we need to specify what processing rules should apply in this case.

Roberto

Received on Thursday, 23 May 2002 10:47:39 UTC