<bold><fixed><fontfamily><param>Courier New</param><color><param>0000,0000,0000</param>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 

<underline>http://www.w3.org/2001/12/soap-envelope</underline> >
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 

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


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

</color></fontfamily></fixed></bold>