Re: Open Content Model

Hi Glen,

IMO there's a semantic difference between "mustUnderstand" and 
"required." We may need both, but what WSDL 1.1 has is "required",
of course.

Sanjiva.

----- Original Message ----- 
From: "Glen Daniels" <gdaniels@macromedia.com>
To: <www-ws-desc@w3.org>
Sent: Thursday, April 25, 2002 12:24 PM
Subject: FW: Open Content Model


> 
> Oops!  This should have gone to the list.  --G
> 
> -----Original Message-----
> From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com]
> Sent: Thursday, April 25, 2002 11:54 AM
> To: Glen Daniels
> Subject: RE: Open Content Model
> 
> 
> Glen, did you want this message to go to the list or just me? --Jeff
> 
> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com] 
> Sent: Thursday, April 25, 2002 8:29 AM
> To: Jeffrey Schlimmer
> Subject: RE: Open Content Model
> 
> 
> 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:41:16 UTC