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:02:14 UTC