W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: Resolving the Ed Note in Part 1 section 5.1 (was New Issues)

From: Christopher Ferris <chris.ferris@sun.com>
Date: Fri, 25 Jan 2002 08:54:39 -0500
Message-ID: <3C51639F.4040708@sun.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app <xml-dist-app@w3c.org>
+1!

Williams, Stuart wrote:

> Henrik, Noah,
> 
> Just thought that I would self identify as one of the 'Others...' that Noah
> mentions, althoug 'strong' disagreement :
> 
> 
>>>Others strongly disagree, presumably based primarily 
>>>on the (sensible, IMO) concern that lower layers of the 
>>>architecture shouldn't be messing with an encaspulated 
>>>message.
>>>
> 
> In a discussion between TBTF participants (archived at [1]) I made the
> following proposal for resolving the ednote in Section 5.1 of part 1 [2],
> which I think is related to this thread of discussion.
> 
> <quote>
> Proposal:
> ---------
> 
> "The combination of the SOAP extensibility model and the SOAP binding
> framework provide some flexibility in the way that particular features can
> be expressed . Features expressed within the SOAP envelope MUST be expressed
> in accordance with the relevant SOAP Module specification. Features
> expressed outside of the SOAP Envelope (typically in a manner that is
> specific to the underlying protocol) MUST be expressed in accordance with
> the relevant protocol binding specification. In cases where, for a given
> message exchange, a given feature is made available by more than one SOAP
> module and/or protocol binding, a SOAP node has complete discretion over
> which particular SOAP module or protocol binding it delegates provison of
> the given feature for the given message exchange. The particular choice may
> be influenced by the combination of features require by the message exchange
> and any other local factors, such as application preferences."
> 
> Possible addition constraining the behaviour of a protocol binding:
> 
> "A SOAP binding is required to convey an XML infoset representing a SOAP
> envelope and its contents between peer SOAP nodes without modification. An
> instance of a SOAP binding MAY inspect, but not alter, the XML infosets
> being exchange."
> </quote>
> 
> I think the additional piece if included (and wordsmithed) comes close to
> addressing Henrik' concern:
> 
> 
>>One approach would be to say that the binding must
>>pass through all unused information items unchanged. If this is the
>>case, then I think a great deal of my concern would go away although
>>this seems to be at least editorially located in another 
>>place than the current ednote
>>
> 
> The rationale I offer for the inclusion of the additional sentences is also
> given in [1] as:
> 
> <quote>
> The second, perhaps grayer question, is whether a binding can recognise the
> elements with the envelope that provide a feature that the binding itself is
> capable of supporting and having recognised such elements, remove them from
> the envelope and substitute it's own mechanisms for providing the *same*
> functionality - after all... who would know? 
> 
> My own answer to that question is NO. The SOAP provider has made the choice
> of which provider of a feature to use, Module or Binding (indeed possibly
> selected between many modules and many bindings that provide overlapping
> functionality). Having made that choice, it is not possible for the binding
> to know whether the elements it snoops on were introduced by the SOAP
> provider or whether they originate from the SOAP User. Basically, I believe
> that the role of the binding is to convey an XML Infoset representing the
> SOAP enevlope and its contents from one binding peer to another without
> altering the content of that infoset (there are unresolved questions about
> infoset equivalence concerning the lexical devices such as ns prefixes and
> lexical representation of schema datatypes of equivalent value, let alone
> issues related to signatures and encryption).
> </quote>
> 
> Regards,
> 
> Stuart
> [1] http://lists.w3.org/Archives/Public/www-archive/2002Jan/0111.html
> [2] http://www.w3.org/TR/soap12-part1/#NA54
> 
> 
>>-----Original Message-----
>>From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
>>Sent: 24 January 2002 19:23
>>To: Noah Mendelsohn; Marc Hadley <marc.hadley
>>Cc: xml-dist-app
>>Subject: RE: New Issues
>>
>>
>>
>>A related issue may be that I think we have been leaning 
>>towards letting
>>it up to the binding to determine how the envelope as a whole is
>>represented, whether it involves an XML 1.0 representation or 
>>something
>>else. As we seem to have settled on the binding not being a SOAP node
>>but a part of one, I think the question boils down to the 
>>issue of what
>>exactly we mean by representing. 
>>
>>Representing an envelope potentially includes not only representing
>>individual header blocks and the body, but all parts of the envelope
>>including cross-references and other interdependencies that may be
>>defined outside the SOAP 1.2 specification. 
>>
>>One potential problem in our current specification is that XML Infoset
>>doesn't define any conformance rules but leaves it up to the
>>specification that uses it to define which parts are being 
>>used. In the
>>context of a binding, I think at a minimum we have to talk about which
>>parts of the infoset we use and what requirements we impose on parts
>>that we don't use. One approach would be to say that the binding must
>>pass through all unused information items unchanged. If this is the
>>case, then I think a great deal of my concern would go away although
>>this seems to be at least editorially located in another 
>>place than the
>>current ednote.
>>
>>FWIW, for the reason that intermediaries are SOAP nodes, I think even
>>though this may be related, the issue of what intermediaries can do is
>>different, simply because they are first class objects.
>>
>>Henrik
>>
>>
>>>This was the subject of an unresolved "debate", leading to the 
>>>inclusion of the ednote as a marker that further consideration 
>>>is needed.  I tend to side with you:  the transport binding 
>>>specs should have freedom to (re)express features in a 
>>>binding-specific manner, even if they started out as simple 
>>>headers.  Others strongly disagree, presumably based primarily 
>>>on the (sensible, IMO) concern that lower layers of the 
>>>architecture shouldn't be messing with an encaspulated 
>>>message.  It's possible that the answer may yet be indirectly 
>>>related the issue Henrik and I started discussing on 
>>>yesterday's call, as to how much discretion intermediaries 
>>>have to mess with the envelope.  It's not the same concern, 
>>>but both affect the rules by which an envelope does or doesn't 
>>>get looked at or changed while flowing through the network.
>>>
> 
Received on Friday, 25 January 2002 08:55:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT