RE: Open Content Model

Hi Sanjiva!

So is this the difference:

  <soap:module name="http://my.com/TransactionID" wsdl:MustUnderstand="true"/>

means "you have to understand the soap:module element", but:

  <soap:module name="http://my.com/TransactionID" wsdl:required="true"/>

means "you have to actually engage the TransactionID module when you use this service"?

Hm, that doesn't seem all that useful... Why would you bother with MustUnderstand if required was false?  How could you allow MustUnderstand to be false if required was true?

Could you describe your take on the difference, and provide an example where you think it's relevant and useful?

Thanks,
--Glen

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Friday, April 26, 2002 5:38 AM
> To: www-ws-desc@w3.org
> Subject: 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 08:18:38 UTC