RE: Proposal for dealing with root, top-level multi-refs and enco dingStyle

Comments with respect to encodingStyle.
 
While I agree encodingStyle doesn't make sense on SOAP elements (Envelope,
Body, Header and Fault), I am not sure the desired effect needs to be
achieved only by NOT allowing encodingStyle AII on these elements. 
 
Allowing encodingStyle on SOAP elements makes it convenient to put this
information on a higher level element (especially if the message is dealing
with a single encoding style). Otherwise (which is as per your proposal),
one need to repeat this encodingStyle on all the header blocks and the body
blocks. 
 
Can't we allow encodingStyle to appear on any element but say it doesn't
apply to elements whose [namespace name] property has the value of
http://www.w3.org/2001/12/soap-envelope
<http://www.w3.org/2001/12/soap-envelope> . I am assuming the other wordings
(that it applies to itself and its decendants) will be left as it is. 
 
Murali
 

 -----Original Message-----
From: Martin Gudgin [mailto:martin.gudgin@btconnect.com]
Sent: Monday, May 06, 2002 12:04 PM
To: xml-dist-app@w3.org
Subject: Proposal for dealing with root, top-level multi-refs and
encodingStyle



In the past we have tried to talk about the notion of root, top-level
multi-refs and encodingStyle seperately. 

Here is a proposal that looks at all of them at the same time in order to
produce a coherent solution. 


In the current description of the SOAP Encoding, outbound 

edges of a graph node are encoded as child EIIs which means that a given 

serialization will always have a single top-level serialization 

root. Multiple top-level serialization roots can only be 

achieved by cross referencing between serialization trees. 

From the SOAP Encoding perspective, such practice will still 

result in but a single graph upon deserialization. 


So, we have a very clear mechanism for establishing 

multiple roots by cross referencing between serialization 

trees when this is desired. We avoid having non-roots 

being mistaken for roots by inline serialization within a 

single serialization tree when this is desired. 


Given this, the notion of root at the serialization level 

seems unnecessary and the 

notion of root in the data model seems trivial to state. 


In the special case of the RPC convention, we clearly state 

that a call and a response is modeled as a single struct 

which prohibits a Body EII from containing multiple roots. 

One could of course imagine cross referencing to a header 

block but that would still explicitly mark the single struct 

in the Body as the "call" or "response". Hence, in this case, 

the "root" AII is not needed either. 


Which brings us to encodingStyle AII. Currently the 

encodingStyle AII applies to the EII it appears on and 

that EII's descendants. In the RPC case this means the 

child of the Body EII and *not* the Body EII itself. The 

reason is that the call and response is identified as a 

single struct, and that struct is *not* the Body EII but a child EII of 

the Body EII. 


The encodingStyle AII does not make sense on soap:Envelope, 

soap:Header as those elements are defined in our spec and do 

not have an encoding style. In fact, the schema description 

of Envelope and Header already disallow attributes from the 

http://www.w3.org/2001/12/soap-envelope > namespace. 


While potentially possible to use the encodingStyle AII in non-RPC 

convention cases and have the Body EII be modeled as a 

struct, this doesn't seem to be an interesting edge case to 

support. In the interests of consistency I would therefore argue that we
disallow the encodingStyle AII on Body too. 


So, in terms of concrete changes to our spec; 


1. State that the notion of root in the data model is as 

follows: "A graph node is said to be a root of the graph if 

it has no inbound edges". 


2. In Part 1 Section 5.1.1 state that encodingStyle AII is 

only legal on descendants of soap:Header and soap:Body ( and 

probably soap:Detail ) by stating: 


"The encodingStyle attribute MAY appear on any element 

information item in a SOAP message except those whose 

[namespace name] property has the value 

"http://www.w3.org/2001/12/soap-envelope"" 


3. Amend the envelope schema as follows: Change the value of 


        /xs:schema/xs:complexType[@name='Body']/xs:anyAttribute/@target 

        Namespace to ##other ( from ##any ). 


Regards 


Gudge

Received on Monday, 6 May 2002 17:23:34 UTC