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 21:45:11 UTC