- 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>
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/
Received on Sunday, 9 December 2001 15:03:44 UTC