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

Sorry, wrong thread. Please disregard.

DB


> -----Original Message-----
> From: Don Box [mailto:dbox@microsoft.com]
> Sent: Friday, January 25, 2002 2:48 PM
> To: xml-dist-app
> Subject: 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 18:12:23 UTC