Re: Proposal to Resolve encodingStyle Issues #5 and #30

SOAP 1.2 introduces the notion of features. Features might be implemented via SOAP protocol bindings or SOAP header
blocks. It is envisaged that a number of useful features will be made available over time, in particular as header
blocks.

In the future, a single SOAP message might thus contain application specific headers, plus boiler plate
headers/features, much in the same way that today an XML document can contain elements from different namespaces.
Restricting the encodingStyle to be unique accross messages would prevent, for example, a message to contain
features that use a different encoding.

I think a reasonnable compromise would be to disallow the encoding to change within a given SOAP header block, but
to allow different blocks to have different encodings.

Jean-Jacques.

ryman@ca.ibm.com wrote:

> Accordingly to http://www.w3.org/TR/soap12-part1/ the encodingStyle
> attribute can occur on any child element of a header, body, or detail.
> Therefore 3.2 allows you to describe the message more faithfully.
>
> Is the freedom to allow multiple encoding styles within a single message
> useful, or is it as useless as allowing a list of encodingStyle URIs was?
> FYI, I have created messages that combine literal and SOAP encoding in a
> single message, but they don't interoperate with .NET. Therefore I wonder
> if in the quest for interop the industry will settle on using a single
> encoding style within a message.
>
> Arthur Ryman
>
>
>                     "Jean-Jacques
>                     Moreau"                To:     Arthur Ryman/Toronto/IBM@IBMCA
>                     <moreau@crf.cano       cc:     www-ws-desc@w3.org, ruellan@crf.canon.fr
>                     n.fr>                  Subject:     Re: Proposal to Resolve encodingStyle Issues #5 and #30
>                     Sent by:
>                     www-ws-desc-requ
>                     est@w3.org
>
>
>                     06/27/2002 05:03
>                     AM
>                     Please respond
>                     to "Jean-Jacques
>                     Moreau"
>
>
>
> I agree with restricting the value of encodingStyle to be a single URI.
> Multiple URIs are no longer supported by SOAP 1.2. Mutliple URIs were
> supported
> by SOAP 1.1, but hardly ever used. (The perceived semantics of multiple
> URIs
> was unclear. The intended semantics was a list of overlapping, more-to-less
> specific encoding styles.)
>
> I think only option 3.2 is available, since SOAP 1.2 only allows the
> encodingStyle AII on SOAP header blocks, SOAP body blocks and the SOAP
> fault
> Detail element (and all their descendants).
>
> Does this make sense?
>
> Jean-Jacques.
>
> ryman@ca.ibm.com wrote:
>
> > Summary of Issues
> >
> > Issue 5: Issue 5:
> >
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x5
> >
> > SOAP allows the encodingStyle attribute on any element of the message.
> The
> > WSDL 1.1 SOAP binding only allows the encodingStyle attribute on the body
> > element.
> >
> > Issue 30:
> >
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x30
> >
> > There are two parts to this issue:
> > 30a: WSDL 1.1 allows a list of URIs as the value of the encodingStyle
> > attribute, but SOAP 1.2 only allows a single URI.
> > 30b: Same as #5.
> >
> > Proposed Resolutions
> >
> > 1. Close issue #5 as a duplicate of #30.
> >
> > 2. Issue 30a
> >
> > This is not really a problem, since when describing a SOAP 1.2 message,
> > just use a single URI in the WSDL. Continue to use a list of URIs to
> > describe SOAP 1.1 messages. I think the point of this issue is really
> > whether we should also restrict the encodingStyle value to be a single
> URI
> > in WSDL 1.2. Herve Ruellan should confirm that this is the correct
> > interpretation.
> >
> > I recommend we restrict the value of encodingStyle to be a single URI
> since
> > in practice people seem to be using a single URI. Several interop
> problems
> > have arisen in the area of encoding style so having a single URI is a
> > useful simplification. Also, since SOAP 1.2 has adopted this position, it
> > seems overkill to maintain support for lists of URIs in WSDL.
> >
> > 3. Issue 30b
> >
> > Pick one of the following solutions. I recommend 3.1.
> >
> > 3.1 Leave this as a limitation of WSDL. This is acceptable if we believe
> > that most messages will use a single encoding style. This appears to be
> the
> > approach that is being taken by WS-I.org.
> >
> > 3.2 Extend the SOAP binding to allow an encoding style to be specified
> for
> > each message part. This makes sense if we believe that individual message
> > parts will have a single encoding style. The syntax of the extension is
> > deferred to the SOAP binding specification.
> >
> > Arthur Ryman

Received on Thursday, 27 June 2002 10:20:03 UTC