W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Summary of Issue 194 - encodingStyle

From: Jacek Kopecky <jacek@systinet.com>
Date: Thu, 11 Apr 2002 04:11:47 +0200 (CEST)
To: Martin Gudgin <marting@develop.com>
cc: XML Protocol Discussion <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.44.0204110255440.3169-100000@mail.idoox.com>
 Gudge, nice writeup, really.
 I prefer P3.
 To the question of what it means to have an outbound edge (Blob) 
marked with a different encodingStyle I have the following 

 In SOAP Encoding we have edges and nodes. An edge is formed by
the name of an element, possibly some namespace declarations and
a ref attribute. A node is formed by the child information items
of an element, except for ref and id attributes.
 So in SOAP Encoding it's possible to say that the edge is kept 
in SOAP Encoding but the value is a terminal graph node (i.e. the 
whole XML subtree is the same as one int from the POV of SOAP 

 On the other hand this brings up an "interesting" question 
demonstrated by the following simple example (not aiming to be 
fully correct XML excerpt):

   <x encodingStyle="soap encoding">
     <a ref="foo"/>
   <b encodingStyle="" id="foo">...</b>

 In words - on <b> the id is not SOAP Encoding ID because it's 
not in our namespace, but then again this should be equivalent to 

   <x encodingStyle="soapEncoding">
     <a encodingStyle="">...</a>

 And in SOAP Encoding we cannot just push the encodingStyle on 
the blob one layer lower because then the blob becomes a struct 
and the situation is repeated, just one layer lower. And there 
would come the schema problem mentioned under the quoted example 
 That's UNLESS we allow terminal nodes to be any node, not only 
with lexical value (which I take to mean "without subelements"). 
Then, I expect, the decision on what is a terminal would be in 
the upper layer (application). And a change of encodingStyle on a 
SOAP Encoding node would be an error. What do you think?

 I have to add the (lately too frequent) disclaimer that if I'm 
not clear, I can blame the hour, so flame me and I'll try to 
reformulate. 8-) [No, really, it's not that bad.]

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Wed, 10 Apr 2002, Martin Gudgin wrote:

 > The proposals:
 > P1: Retain the status quo
 > P2: For Q1 - Disallow encodingStyle on Envelope and Header. For Q2 - keep
 > status quo.
 > P3: For Q1 - Disallow encodingStyle on Envelope, Header and Body. For Q2 -
 > keep status quo.
 > P4: For Q1 - Disallow encodingStyle on Envelope and Header. For Q2 - state
 > that the encodingStyle attribute only applies to the descendants of the
 > element it appears on.
 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 > P3:
 > <s:Envelope xmlns:s='http://www.w3.org/2001/12/soap-envelope'
 >             xmlns:m='http://example.org/headers' >
 >   <s:Header>
 >     <m:First soap:encodingStyle='http://www.w3.org/2001/12/soap-encoding' >
 >        I'm some data in a terminal node
 >     </m:First>
 >     <m:Second soap:encodingStyle='http://www.w3.org/2001/12/soap-encoding' >
 >       <m:Data>
 >         Data
 >       </m:Data>
 >       <m:MoreData>
 >         More data
 >       </m:MoreData>
 >     </m:Second>
 >     <m:Third >
 >       <m:Data value='data' />
 >       <m:MoreData value='more data' />
 >     </m:Third>
 >   </s:Header>
 >   <s:Body>
 >     <r:MyRequest xmlns:r='http://example.org/webservices/mystuff'
 > soap:encodingStyle='http://www.w3.org/2001/12/soap-encoding'>
 >       <r:Terminal>
 >         I'm data in a terminal
 >       </r:Terminal>
 >       <r:NonTerminal>
 >         <edge>Data</edge>
 >         <otheredge>More data</otheredge>
 >       </r:NonTerminal>
 >       <r:Blob soap:encodingStyle=''>
 >         <data data='hello'>
 >           <child value='data' />
 >           <child value='data' />
 >           <child value='data' />
 >           <child value='data' />
 >         </data>
 >       </r:Blob>
 >     </r:MyRequest>
 >   </s:Body>
 > </s:Envelope>
 > Observations: What does it mean to have an outbound edge ( Blob ) marked
 > with a different encodingStyle? Could move attribute down onto 'data'
 > element but then if this element is being described using a schema that
 > schema has to allow the encodingStyle attribute in order for validation to
 > succeed.
Received on Wednesday, 10 April 2002 22:11:54 UTC

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