Re: Encoding: encodingStyle issues

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.
-Dug


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>
cc:
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
graph?
 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)
                   http://www.systinet.com/