W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: Encoding: encodingStyle issues

From: Doug Davis <dug@us.ibm.com>
Date: Sun, 9 Dec 2001 15:03:32 -0500
To: Jacek Kopecky <jacek@systinet.com>
Cc: <xml-dist-app@w3.org>
Message-ID: <OF1A966B69.0DCF8AC4-ON85256B1D.006DB4F9@raleigh.ibm.com >
I always viewed the encodingStyle attribute slightly
differently - I didn't view it as "this element, and
its children, are encoding with this style" but rather
"when interpreting this element, and its children,
if a decoding scheme is needed then use this style".
It seems like if we head down the path you're suggesting
and having it on a higher-level element would not be
allowed, then by inference not having it on an element
would be an error - and therefore, would need to have
an encoding style that says "this is an RPC", for example,
right?  I'm not sure that would be a good idea.

Jacek Kopecky <jacek@systinet.com>@w3.org on 12/09/2001 02:24:25 PM

Sent by:  xml-dist-app-request@w3.org

To:   <xml-dist-app@w3.org>
Subject:  Encoding: encodingStyle issues

 Hi all. 8-)
 During the F2F Encoding test generation we encountered the
second issue in this message, thinking about which lead me to
the first one:
 In SOAP we have the attribute encodingStyle that indicates the
element and its children are encoded using an encoding indicated
by its value.
 The first issue: can this attribute be really present on
Envelope, Body, Header or Fault elements? I think not because the
elements' contents are not deserialized using the Encoding
serialization rules (or any encoding serialization rules, for
that matter).
 The second issue: does the presence of the encodingStyle
attribute, even with the same value as on the first ancestor of
this element that has this attribute, mean a break in the data
 Again, I think not as I can't think of what such a break would
mean to the deserialized data.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
Received on Sunday, 9 December 2001 15:03:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:17 UTC