RE: Revised extensibility proposal

Well, how about this:

<wsdl:description xmlns:myext="uri:myext"...
<wsdl:extension namespace="uri:myext" required="true"/>

<wsdl:message ...
<myext:pipe ...
<myext:model required="false" link="pipe.uml"...

Is that an edge case too?

Simplicity is very good, but not by restricting usefulness. There got to be other ways of making things simple.

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



-----Original Message-----
From: Keith Ballinger [mailto:keithba@microsoft.com] 
Sent: Wednesday, May 22, 2002 10:05 PM
To: Roberto Chinnici; Jonathan Marsh
Cc: www-ws-desc@w3.org
Subject: RE: Revised extensibility proposal


>>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.
 
I think this is really an edge case. 
 
We should strive for simplicity. It looks like Jon's suggestion is the simpler, and still covers the use cases that matter. If a processor doesn't understand soemthing that he must, he fails.

	-----Original Message----- 
	From: Roberto Chinnici [mailto:roberto.chinnici@sun.com] 
	Sent: Wed 5/22/2002 4:58 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:51:31 UTC