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 Wednesday, 5 June 2002 21:57:22 UTC