RE: Rationale for Dropping the <soap:body use=...> Attribute

I concur. The issue was not scope (at least that's not what I heard as a 
justification).
   The arguments included reducing options to increase interoperability 
(while still maintaining enough functionality for the target apps) and 
having a type system one could count on being there. Hence using XSD as 
"the" WS type system and mandating a single encoding.
    jeff

At 08:56 AM 9/26/2002, David Orchard wrote:
>+1 to gudge's point.  That's certainly my recollection of the ws-i meetings
>and main issue around encoding.
>
>I wouldn't have a problem with wsdl not supporting soap encoding.  But then
>I didn't have a problem with soap 1.2 not supporting encoding ;-)
>
>cheers,
>Dave
>
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Martin Gudgin
> > Sent: Wednesday, September 25, 2002 1:19 PM
> > To: Anne Thomas Manes; Jacek Kopecky; ryman@ca.ibm.com
> > Cc: WS Description WG
> > Subject: RE: Rationale for Dropping the <soap:body use=...> Attribute
> >
> >
> >
> > Anne,
> >
> > I don't think reducing scope was the main reason. A awful lot
> > of interop
> > problems are attributable to SOAP Encoding in SOAP 1.1 and/or
> > use='encoded' in WSDL 1.1
> >
> > The WS-I BP WG was satisfied that use='encoded' was
> > unnecessary. And we
> > are not just making a recommendation that you SHOULD say
> > use='literal',
> > we are saying you MUST say use='literal'.
> >
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: 19 September 2002 06:31
> > > To: Jacek Kopecky; ryman@ca.ibm.com
> > > Cc: WS Description WG
> > > Subject: RE: Rationale for Dropping the <soap:body use=...>
> > Attribute
> > >
> > >
> > >
> > > One more point:
> > >
> > > WS-I has chosen to not include Encoded in the Basic profile.
> > > That isn't quite the same thing as saying that they have made
> > > the recommendation to use only Literal. This was a hefty
> > > topic of debate, and one of the primary reasons why they
> > > decided not to include Encoded was to reduce the scope of the
> > > Basic profile.
> > >
> > > Anne
> > >
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> > > [mailto:www-ws-desc-request@w3.org]On
> > > > Behalf Of Jacek Kopecky
> > > > Sent: Thursday, September 19, 2002 8:07 AM
> > > > To: ryman@ca.ibm.com
> > > > Cc: WS Description WG
> > > > Subject: Re: Rationale for Dropping the <soap:body use=...>
> > > Attribute
> > > >
> > > >
> > > >
> > > >  Arthur,
> > > >  just two points:
> > > >
> > > >  1. By constraining oneself to XML Schema as the abstract
> > > type system,
> > > > one constrains oneself to the tree data model inherent in
> > > XML Schema,
> > > > other data models being out of reach (describing other data
> > > models in
> > > > XML Schema is at best a kludge). For example - what if I want to
> > > > transfer some specific RDF data in a service? How do I
> > describe the
> > > > service using only XML Schema?  It is true that the real
> > > > representation need not be XML, but this is an orthogonal topic.
> > > >
> > > >  2. WS-I doesn't seem to support SOAP Encoding in their
> > activities,
> > > > and if I understand you correctly, they are in fact
> > > creating their own
> > > > graph encoding. It is understandable for them, but I don't
> > > think it is
> > > > possible for WSDL 1.2 not to support SOAP Encoding
> > properly, since
> > > > SOAP Encoding is part of SOAP 1.2 - the product of a peer
> > > W3C Working
> > > > Group - and the WS-Desc WG has sent no comments against
> > > SOAP Encoding
> > > > in the Last Call phase.
> > > >
> > > >                    Jacek Kopecky
> > > >
> > > >                    Senior Architect, Systinet Corporation
> > > >                    http://www.systinet.com/
> > > >
> > > >
> > > >
> > > > On Wed, 2002-09-18 at 19:35, ryman@ca.ibm.com wrote:
> > > > >
> > > > > Jacek,
> > > > >
> > > > > I think it's useful to seperate the discussion into two parts:
> > > > >
> > > > > 1) abstract (binding neutral) definition of messages in WSDL
> > > > > 2) format of messages in the SOAP binding
> > > > >
> > > > > Concerning 1) I am in favour of just using XML schema. In fact,
> > > > > there is also discussion that the <message> element be
> > > removed and
> > > > > that
> > > > messages be
> > > > > directly defined using schema, i.e. without <part>s. Allowing
> > > > > different schema languages is a step in the opposite direction.
> > > > >
> > > > > Concerning 2) the WS-I.org recommendation is to just
> > use literal.
> > > > > Also, WS-I.org is working on an algorithm to encode
> > > graphs in a way
> > > > that can be
> > > > > described using a literal schema. So if the concrete message
> > > > format is XML,
> > > > > then I see little benefit in allowing the concrete schema to be
> > > > different
> > > > > than the abstract schema. However, there are important
> > > cases where
> > > > > the concrete message format is not XML. For example, in
> > > HTTP GET the
> > > > > input parameters are url encoded. (e.g. the input gets
> > encoded as
> > > > symbol=IBM and
> > > > > not as <symbol>IBM</symbol>). Also, if the message
> > > includes binary
> > > > > resources, then we can describe them abstractly as some
> > > restriction
> > > > > of xsd:hexBinary, but the concrete message format could
> > be a MIME
> > > > type such as
> > > > > image/jpeg using SOAP with attachments.
> > > > >
> > > > > To summarize:
> > > > > - First, we should view the message definition as
> > > abstract and use
> > > > > XML Schema as the abstract data type language. This
> > establishes a
> > > > > proper layering in WSDL by isolating the message
> > > definition from the
> > > > > bindings. -Second, we should define the concrete message
> > > format in
> > > > > the binding. -Third, evidence from WS-I.org tells us
> > that for the
> > > > > SOAP
> > > > binding, we can
> > > > > live with literal only for concrete XML messages.
> > > > > -Fourth, using literal only doesn't mean that the
> > > abstract message
> > > > > definition is always concrete since there are other important
> > > > > non-XML formats such as url encoding and MIME.
> > > > >
> > > > > Arthur Ryman
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > >                       Jacek Kopecky
> > > >
> > > >
> > > > >                       <jacek@systinet.c        To:       Arthur
> > > > Ryman/Toronto/IBM@IBMCA
> > > >
> > > > >                       om>                      cc:       WS
> > > > Description WG <www-ws-desc@w3.org>
> > > >
> > > > >                                                Subject:  Re:
> > > > Rationale for Dropping the <soap:body use=...> Attribute
> > > >
> > > > >                       09/18/2002 12:11
> > > >
> > > >
> > > > >                       PM
> > > >
> > > >
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >  Arhur,
> > > > >  if you want an abstract schema at the wsdl:message
> > > level, that's OK
> > > > > with me and it's understandable. On the other hand, if
> > > you want to
> > > > > remove the use attribute by saying that "literal XML
> > > Schema" is the
> > > > > only possible way in SOAP, I disagree because that either
> > > results in
> > > > > ugly
> > > > > *and* ambiguous data structure schemata or in disallowing
> > > other data
> > > > > models altogether (with SOAP Data Model among them).
> > > > >  I think that especially because the parts of
> > > wsdl:message should be
> > > > > described abstractly, we may need different data models
> > > right here,
> > > > > otherwise we'll say that, abstractly, WSDL only describes
> > > services that
> > > > > can transfer trees with very raw untyped references.
> > > > >  So, either let's keep use="encoded" or let's allow
> > > different schema
> > > > > languages (other than XML Schema), and I prefer the
> > > latter because it
> > > > > agrees with the requirement "abstract description of
> > wsdl:message
> > > > > parts".
> > > > >  Best regards,
> > > > >
> > > > >                    Jacek Kopecky
> > > > >
> > > > >                    Senior Architect, Systinet Corporation
> > > > >                    http://www.systinet.com/
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >

Received on Saturday, 28 September 2002 19:58:05 UTC