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 Wednesday, 22 May 2002 22:05:37 UTC