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

+1 from me as well. I believe SOAP (and WSDL) should deal exclusively in

+terms of XML Schema types and defer language/type system mappings to 
+specs that are independent of SOAP.

DB

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Friday, January 25, 2002 5:55 AM
> To: Williams, Stuart
> Cc: Henrik Frystyk Nielsen; Noah Mendelsohn; xml-dist-app
> Subject: Re: Resolving the Ed Note in Part 1 section 5.1 (was New
Issues)
> 
> +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 17:48:41 UTC