Re: Encoding: encodingStyle issues

 Dug,
 I can understand the way you see the meaning of encodingStyle on
an element, and I like it, and I'd like it to be in the spec or
in the primer. 8-)
 However, I don't think that RPC would need a special encoding
style because it uses SOAP Encoding, actually. And not having
encodingStyle on an element would just mean "there are no claims
about the encodingStyle used on this piece of data - do whatever
you will do". 8-)
 Anyway, again, some clarification needed in the spec, it seems.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Sun, 9 Dec 2001, Doug Davis wrote:

 > 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 Monday, 10 December 2001 15:29:25 UTC