Re: Open Content Model

Alternatively we can introduce another attribute:
    wsdl:requiredAttributes="qname1 ... qnamen"
which will identify the attributes which are required to be
understood.

Ugly as it is, at least that would provide consistent
behavior for attributes and elements.

In any case, I can live with  open-contentness with something
like the clarifying clauses that Jonathan indicated.

Bye,

Sanjiva.

----- Original Message ----- 
From: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
To: <www-ws-desc@w3.org>
Sent: Wednesday, April 24, 2002 9:41 PM
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 Wednesday, 24 April 2002 22:32:34 UTC