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