Re: Proposal for dealing with root, top-level multi-refs and encodingStyle

 Gudge,
 I like what you're proposing about encodingStyle, but I believe 
the other change about roots misses the point.
 The notion of an explicit root in SOAP 1.1 was there because 
SOAP Encoding then also mandated that (almost) all multirefs be 
serialized "on top level of serialization" and there we needed to 
know which of the element IIs was the true *serialization* root.
 You are trying to add the notion of a graph root. This is 
utterly unnecessary because we don't need it elsewhere in the 
spec and you're just restating the common definition of the term 
so it's not adding anything novel.
 On the other hand you dismissed the *serialization root* term by 
saying 

 > We avoid having non-roots being mistaken for roots by inline
 > serialization within a single serialization tree when this is
 > desired.

 We have never openly forbidden the out-of-line serialization 
mandated in SOAP 1.1, so technically, while it cannot be achieved 
using our current rules, nothing in our spec says that only a 
serialization root can be serialized independently.
 Granted, implementors of SOAP who start with SOAP 1.2 will have 
no problem with this, but implementors who move from SOAP 1.1 
might keep their out-of-line-serializing implementations. Without 
the enc:root attribute (and the notion of *serialization root* 
along with it) they won't be able to tell the real serialization 
root and they will use ad hoc non-interoperable techniques like 
"the first is the root" or even a (nonexistent - illegal) root 
AII in our encoding namespace.
 So I have a counterproposal which will clarify this situation 
and not add anything unnecessary:

 1) We will not add the notion of a root anywhere.
 2) We will state in the serialization rules that "unless a node
has been serialized before and could therefore be linked to, it
MUST be serialized in its edge EII".

 This will force inline serialization and suppress the need for 
root attribute.
 Best regards,
 

                   Jacek Kopecky

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



On Mon, 6 May 2002, Martin Gudgin wrote:

 > 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:24:24 UTC