Re: Open Content Model

From the WSDL 1.1 spec.

"To distinguish whether the semantic of the technology specific binding is
required for communication or optional, extensibility elements MAY place a
wsdl:required attribute of type boolean on the element."

To me this definitely means that the WSDL processor must understand the
extension element marked with the wsdl:required attribute. Whether it means
that the content implied by the extension element marked with the
wsdl:required attribute has to be present in the message is less clear. I
would lean towards guessing that it does.

Si.
----- Original Message -----
From: "Matt Long" <mlong@phalanxsys.com>
To: "'Sanjiva Weerawarana'" <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
Sent: Friday, April 26, 2002 12:12 PM
Subject: RE: Open Content Model


> Asking for clarification...
>
> My understanding of wsdl:required is that the processor is 'required' to
> understand the extension element (not that the extension element is
> 'required' to be present in the message) encoded with wsdl:required. It
> seems that under certain situations (for instance a security-ish
> soap:header) that this soap:header may be 'required' to be present in
> the message.  As I understand it, it is not possible to communicate this
> directly under WSDL 1.1.
>
> Considering that security is a significant issue *and* that requirements
> for security headers in messages are a given for specific use cases, how
> can this be addressed?
>
> Comments!
>
> Thx,
>
> -Matt Long
> Phalanx Systems, LLC
>
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On
> > Behalf Of Sanjiva Weerawarana
> > Sent: Friday, April 26, 2002 4: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 09:57:27 UTC