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

RE: Revised extensibility proposal

From: Keith Ballinger <keithba@microsoft.com>
Date: Wed, 22 May 2002 19:05:04 -0700
Message-ID: <2BB6686A81A0AD46AF23522309B6CC00011EDE66@RED-MSG-10.redmond.corp.microsoft.com>
To: "Roberto Chinnici" <roberto.chinnici@sun.com>, "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: <www-ws-desc@w3.org>
>>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 Wednesday, 22 May 2002 22:05:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT