RE: Issue with encodingStyle

I think the answer to the original question is (b):  the originator is 
choosing not to use SOAP mechanisms tell you anything about the encoding 
of the message.  The receiver may or may have more application-specific 
ways of interpreting the structure of the message, e.g. you might 
recognize the QName of the element, but you have chosen not to use the 
mechanism that would give a generalized SOAP processor a start. Therefore, 
such a processor is likley to treat the data as XML.

>> Specifically, how to explicitly mark an element as literal XML.

I think that in some sense, all SOAP messages including encoded are 
literal XML.  If you mean to say specifically that you intend the data to 
be modeled per XML schema, or some other convention, then you can invent 
an encoding URI to convey that.  Setting encodingStyle doesn't mean you've 
mangled the data, just that you've documented its representation.  I'm not 
sure I see the need to create an explicit literal XML URI as part of the 
SOAP spec, as I'm not sure what it would convey that's different from 
specifying no encoding.  

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Matt Long" <mlong@phalanxsys.com>
Sent by: xml-dist-app-request@w3.org
02/06/2002 11:58 AM

 
        To:     <xml-dist-app@w3.org>
        cc: 
        Subject:        RE: Issue with encodingStyle


I would also like to see mixed encoding addressed. Specifically, how to
explicitly mark an element as literal XML.

Thx,

-Matt Long
Phalanx Systems, LLC

> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Bob Cunnings
> Sent: Wednesday, February 06, 2002 10:49 AM
> To: xml-dist-app@w3.org
> Subject: Re: Issue with encodingStyle
>
>
> Hello,
>
> I also shared these concerns... see
>
> http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0055.html
>
> but no response was elicited.
>
> rC
>
> > All,
> >
> > I want to raise an issue with the definition of the encodingStyle
> > attribute in Section 4.1 of SOAP 1.2 Part 1 [1].
> >
> > The spec says that encoded message "SHOULD" indicate their encoding
> > style using the encodingStyle attribute.
> >
> > It also says that if the encodingStyle attribute is set to
> "", no claims
> > are made about the encoding style of an elements contents.
> >
> > The spec does not say how to interpret the absence of an
> encodingStyle
> > attribute. However, given that encoded messages are not
> required to use
> > the encodingStyle attribute, I believe the absence of the
> does not mean
> > that the message is not encoded, but rather that it makes
> no claim about
> > its encoding (eqivalent to encodingStyle="").
> >
> > Can you please clarify the definition of the phrase "makes
> no claims"?
> > If a message does not include an encodingStyle attribute,
> does that mean
> > that:
> >
> > a) the message is NOT encoded
> > b) the message may or may not be encoded, it chose not to say
> > c) something else
> >
> > Based on the current spec, I think the answer is b. This is
> problematic
> > if a SOAP processor is trying to determine how to process a message.
> >
> > I'd like to see the spec revised so that:
> >
> > - messages whose content model is defined based on a set of encoding
> > rules *MUST* indicate their encoding sytle using the encodingStyle
> > attribute
> >
> > - elements without an explicitly stated encodingStyle have
> NO encoding
> > style, i.e., their format is explicitly defined via XSD or
> some other
> > mechanism (elements can turn off their parent's encoding style with
> > encodingStyle="")
> >
> > Thanks,
> > Tim-
> >
> > [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011217/#soapencattr
> >
>

Received on Wednesday, 6 February 2002 18:50:49 UTC