Re: FW: Open Content Model

+1, I like it a lot, symmetry is good!

Regarding the performance problem, this is not worse than SOAP 1.2, and I'd
think this is ok, even for resource constrained devices (which might not use
WSDL anyway, but predefined services).

Jean-Jacques.

Glen Daniels wrote:

> Two comments about wsdl:required.
>
> 1) If in fact the purpose of this is to indicate that the processor who
> is reading this document must comprehend the extension in question for a
> valid interpretation of the WSDL, why don't we change it to
> wsdl:MustUnderstand to mirror the SOAP attribute which indicates
> precisely the same semantics?
>
> 2) Assuming these are the semantics, you can use this, as in SOAP, to
> require understanding of anything, not just EIIs.  Example:
>
> <operation name="foo" myNS:fancyAttribute="idempotent">
>   ...
> </operation>
> <service>
>   <myNS:fancyExtension wsdl:MustUnderstand="true"/>
>   ...
> </service>
>
> So a reader of this document would see the MU="true" on the
> myNS:fancyExtension element, which means that they are required to
> "understand" all semantics and rules indicated by the specification
> which defines this element.  In this case, I'm positing that said spec
> indicates that you must process the "myNS:fancyAttribute" attribute when
> dealing with operations to indicate various characteristics such as
> idempotency.
>
> Elements like myNS:fancyExtension can be defined for fine-grained
> extensions, and then it's easy to aggregate these into groups of
> commonly used stuff which can be indicated with a single MU="true"
> element, something like "<myNS:allMyExtensions>", whose specification
> indicates that understanding it implies understanding "fancyExtesion",
> "superExtension", and "megaExtension".
>
> Does this get us what we want here?  A potential performance problem
> with this is that you need to go and find all the required stuff before
> doing any real work comprehending the document, since the semantics of
> how you parse the rest might be affected.  This also precisely matches
> the SOAP 1.2 processing model, and allows for safe extensibility.
>
> --Glen
>
> > -----Original Message-----
> > From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com]
> > Sent: Wednesday, April 24, 2002 9:41 PM
> > To:
> > Subject: RE: Open Content Model
> >
> >
> > As appealing as it is, wsdl:required can only be used to annotate
> > element information items (EII) but not attribute information items
> > (AII).
> >
> > So, we're going to have to commit to either: (a) AII extensions must
> > _always_ be understood, or (b) AII extensions must always be
> > ignorable.
> > Right?
> >
> > If we choose (a), we have a split rule for interpreting whether an
> > extension is required "by default". That is, an EII without
> > wsdl:required is ignorable but an AII without wsdl:required
> > (which they
> > all will be) must be understood.
> >
> > For the sake of consistency, seems like (b) is a better choice. Can we
> > live with extension AII always being ignorable?
> >
> > --Jeff
> >
> > -----Original Message-----
> > From: Jonathan Marsh
> > Sent: Wednesday, April 24, 2002 4:20 PM
> > To: www-ws-desc@w3.org
> > Subject: RE: Open Content Model
> >
> > > -----Original Message-----
> > > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> > > Sent: Wednesday, April 24, 2002 1:26 PM
> > > To: www-ws-desc@w3.org
> > > Subject: Re: Open Content Model
> > >
> > > I would personally preferred to have open-content on
> > selected elements
> > > rather than saying "arbitrary XML can be inserted
> > anywhere." That is,
> > > I prefer architected open-content rather than flat-out openness.
> >
> > I think open content models are only a small factor in the total
> > extensibility of the language.  The main parts are the
> > processing model
> > and the conformance clauses.
> >
> > > Example: If we decide that the language should not have portType
> > > (interface) inheritance, then having an open-content model would
> > > allow one to easily supplant that restriction by adding an attribute
> > > or element to <portType>. IMO that's bad.
> >
> > You can imagine lots of ignorable annotations on <portType> like
> > my:lastUpdatedOn="20020424" my:lastUpdatedBy="jmarsh@microsoft.com".
> > Ignorable annotations are the 90% case.  How do you distinguish
> > ignorable annotations from behavioral extensions?  Perhaps an open
> > content model together with a processing model like this
> > would meet your
> > concern:
> >
> > 1) extension attributes are allowed everywhere, but cannot change the
> > behavior of elements or attributes described in the spec.
> > 2) extension elements are allowed everywhere, but cannot change the
> > behavior of elements or attributes described in the spec unless marked
> > with wsdl:required="true".
> > 3) it is an error to process a WSDL document with extension elements
> > marked with wsdl:required="true" if the extension is not supported by
> > the processor.
> >
> > > Jonathan: If I recall correctly XSLT is not fully open-content:
> > > weren't there some restrictions on top-level elements and
> > their impact
> > > on the processing model? That's akin to what I would prefer;
> > > architected extensionsibility with good rationale.
> >
> > XSLT has a mechanism for identifying extension elements, and
> > distinguishing them from literal result elements inside of templates.
> > Such extension elements are given an implicit
> > required="true", that is,
> > a processor that doesn't understand the extension must halt and catch
> > fire.  Outside of templates, where there is no ambiguity, arbitrary
> > elements are allowed.  Attribute extensibility is allowed everywhere.
> > The rules given are pretty much like those I give above, although
> > wsdl:required provide a granularity of control not available in XSLT.
> >
> > > Sanjiva.
> > >
> > > ----- Original Message -----
> > > From: "Keith Ballinger" <keithba@microsoft.com>
> > > To: <www-ws-desc@w3.org>
> > > Sent: Monday, April 22, 2002 10:06 PM
> > > Subject: Open Content Model
> > >
> > >
> > > One item I've had on my plate is to describe why the open content
> > model
> > > is something we should try to take advantage of as much as possible
> > with
> > > the WDSL revision.
> > >
> > > To begin with, when I say open content model, I mostly mean allowing
> > > extra element and attributes from other namespaces within a schema.
> > This
> > > is typically done with the <any/> and <anyAttribute/> schema tags.
> > These
> > > elements also allow you to specify which namespace
> > (including ##other,
> > > which means any namespace but the one in the schema), as well as the
> > > default processing of these elements. An example of this
> > can be found
> > > with the <binding> element in WSDL today. This element allows child
> > > elements of the type: <any namespace="##other" minOccurs="0"
> > > maxOccurs="unbounded" />
> > >
> > > Working with SOAP and WSDL over the past few years has shown me the
> > > value in allowing this open content model. It is very useful
> > especially
> > > for extending a specification in new ways. As authors of
> > specs, we may
> > > cover many use cases and requirements in a first class way, but we
> > need
> > > to provide for those other requirements that come to us
> > that we don't
> > > anticipate. The open content model allows us to handle many
> > of these.
> > >
> > > I would also recommend that we keep WSDLs mustUnderstand feature for
> > > extensions, the wsdl:required attribute.
> > >
> > > As a matter of technique, I feel that we should be overly open as
> > > opposed to overly closed. This would lead to putting this
> > open content
> > > model on all elements, and then finding reasons why it
> > shouldn't be on
> > > one.
> > >
> > > Cheers,
> > > Keith
> > >
> >

Received on Friday, 26 April 2002 05:32:49 UTC