Re: Open Content Model

I think that it is important to recognize that SOAP mU characteristics
apply to the *receiving* SOAP node, not to the sending node.

wsdl:required is instructing a *sending* SOAP node to include
the required header block. I don't think that it is necessarily
the case that the sending SOAP node understand (in the SOAPish
sense) the header block it inserts in a message destined for
another SOAP node.

Where mU would come into play might be the case of a service
endpoint that intends on including some SOAP header block
in a response message (in the case of request-response)
and it would be indicating in this case that the originator
of the request message had better be capable of understanding
(in the SOAPish sense) the response header block.

Ergo, I think you may need both wsdl:required and wsdl:mustUnderstand,
required for inbound messages and mustUnderstand for outbound
response messages.

Cheers,

Chris

Glen Daniels wrote:

> 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 09:27:45 UTC