Re: Doubly revised extensibility proposal

The spec for an extension can certainly define its own processing
rules, including what to do in case of failures.

I still see a value in a catch-all clause at the WSDL processor
level: if we choose it wisely, most extensions won't need to
define their own failure reporting/recovery rules, and that
simplifies both the task of WSDL processors as well as that
of users, who have one less thing to memorize when they learn
(or define) a new extension.

This said, I wouldn't mind removing it if it helped us achieve
some substantial simplification in the extensibility model.

Roberto


Jeffrey Schlimmer wrote:
> 
> Our efforts should be limited to defining a means to say that a
> particular foreign EII must be recognized (or not) by a WSDL parser. The
> meaning of the foreign EII is defined by an application spec. Do you
> agree?
> 
> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Wednesday, June 05, 2002 6:57 PM
> To: Jonathan Marsh
> Cc: www-ws-desc@w3.org
> Subject: Re: Doubly revised extensibility proposal
> 
> It seems to me that it's all a problem of terminology.
> 
> When I say
> 
>   "The difference is in the behavior of a processor in case of failure
> at
>     handling the extension element"
> 
> what I mean by "failure at handling the extension element" is not (only)
> a failure at recognizing a certain extension element, but also a failure
> that occurs while I try to process the extension element using whatever
> rules are appropriate for it.
> 
> In other words, the fact that a processor recognizes an extension does
> not guarantee that it'll always succeed in processing it, and that's
> what
> makes case (1) interesting.
> 
> Roberto
> 
> Jonathan Marsh wrote:
> 
> > I don't think you addressed my point.  Yes, case (1) seems interesting
> > until you look at it and realize that the presence of a single element
> > not marked as optional causes the WSDL (along with all of the elements
> > marked as optional) to fail.  So the net effect is as I describe
> below,
> > that there is utility in marking the namespace as required, and
> > individual elements as optional unless they are ALL optional.  In this
> > case having both namespace and element-level granularity doesn't
> provide
> > any benefit.
> >
> > I think your MUST/MUST NOT terminology is what MAY/MUST originally
> > intended (though I've taken the table out of context).  I have
> certainly
> > been looking at the output of the extensibility proposal as a boolean
> > answer to the question - "Do I understand this WSDL or not?"  This
> > should be a simple calculation based on the namespaces in use in the
> > WSDL document, the list of extensions a processor understands,
> > represented by a list of URIs or QNames or whatever, and the wsdl
> > extension flags such as wsdl:extension and @wsdl:required.
> >
> > > -----Original Message-----
> > > From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> > > Sent: Sunday, June 02, 2002 8:21 PM
> > > To: Jonathan Marsh
> > > Cc: www-ws-desc@w3.org
> > > Subject: Re: Doubly revised extensibility proposal
> > >
> > > With the current proposal, there is a difference between the
> following
> > > two cases: (1) having a required extension declaration and an
> > extension
> > > element belonging to it and marked optional; (2) having a required
> > > extension
> > > declaration and an extension element belonging to it and marked as
> > > required
> > > (either by specifying wsdl:required="true" or omitting it).
> > >
> > > The difference is in the behavior of a processor in case of failure
> at
> > > handling the extension element: in the first case, the processor
> MUST
> > > continue processing the document as if the extension element had not
> > > been present, while in the second case it MUST abort processing.
> > >
> > > Incidentally, this shows that there are some aspects of the
> processing
> > > rules contained in my proposal which are not captured by the table.
> > > This can be seen as being either good or bad, of course!
> > >
> > > Roberto
> > >
> > >
> > > Jonathan Marsh wrote:
> > > >
> > > > During the telcon it occurred to me that a couple of values in the
> > table
> > > > for Roberto's proposal have little practical value.
> > > >
> > > >                         -- wsdl:extension omitted
> > > >                         |    -- wsdl:extension @required omitted
> > > >                         |    |    -- wsdl:extension @required
> false
> > > >                         |    |    |    -- wsdl:extension @required
> > true
> > > >                         |    |    |    |
> > > > @wsdl:required omitted MAY  MUST MAY  MUST
> > > > @wsdl:required false   MAY >MAY< MAY >MAY<
> > > > @wsdl:required true    MUST MUST MUST MUST
> > > >
> > > > The values marked >MAY< enable an extension namespace to be marked
> > as
> > > > required, while making specific elements in that namespace
> optional,
> > as
> > > > in the following example:
> > > >
> > > >   <wsdl:extension namespace="uri1" required="true"/>
> > > >   ...
> > > >   <x xmlns="uri1"/>
> > > >   ...
> > > >   <y xmlns="uri1" wsdl:required="false"/>
> > > >
> > > > But, a WSDL processor not understanding the uri1 namespace will
> stop
> > > > when it sees the first required use of this namespace.  So,
> > > > wsdl:required="false" only has utility if there is no
> wsdl:extension
> > > > with required="true" (in which case wsdl:required="false" is a
> > no-op),
> > > > or if every occurrence of the namespace is marked as
> > > > wsdl:required="false" (in which case the presence of
> wsdl:extension
> > with
> > > > required="true" is somewhere between irrelevant and semantically
> > > > inaccurate).
> > > >
> > > > The inverse also seems to have little utility:  wsdl:extension
> with
> > > > required="false" and wsdl:required="true".
> > > >
> > > >   <wsdl:extension namespace="uri1" required="false"/>
> > > >   ...
> > > >   <x xmlns="uri1" wsdl:required="true"/>
> > > >   ...
> > > >   <y xmlns="uri1"/>
> > > >
> > > > The presence of wsdl:required="true" means that a processor not
> > > > understanding the uri1 namespace will stop.  The optionality of
> > > > non-required use of the namespace will not change the behavior.
> > > >
> > > > So, it seems to me that a single instance of a required extension
> is
> > > > enough to cause the whole WSDL to crash and burn.  Doesn't this
> mean
> > > > that any need for finer granularity than a namespace is an
> illusion?
> > > > What differences in behavior are there between the two examples
> > above
> > > > and the example below?  Doesn't this mean that @wsdl:required is
> > > > unnecessary?
> > > >
> > > >   <wsdl:extension namespace="uri1"/>
> > > >   ...
> > > >   <x xmlns="uri1"/>
> > > >   ...
> > > >   <y xmlns="uri1"/>

Received on Thursday, 6 June 2002 09:11:17 UTC