Re: Summary of discussions on dealing with root, top-level multi-refs and encodingStyle

 Marc,
 I agree with the first part about encodingStyle, I disagree with 
many pieces of your second part. Let me rephrase the second part 
in my words (changed pieces marked with asterisks):

* Roots and non-serialization-root top-level elements
* ===================================================

I think there is general agreement to the following:

(i) Graph roots are graph nodes with no inbound edges.
(ii) ids and refs are scoped to the envelope rather than the body or a 
particular header block.
(iii) Cross-block (header->header, header->body, body->header) refs 
result in two otherwise separate graphs becoming a single graph.
* (iv) The current encoding does not forbid top-level
* non-serialization-root multi-refs, it just doesn't mandate them.
* Developers new to SOAP 1.2 would be unlikely to produce software that
* generated top-level non-serialization-root muti-refs, but migration
* from existing SOAP 1.1 codebases may produce software that generates
* top-level multi-refs.
* (v) When using the RPC convention we need a way of identifying the EII 
* that represents the RPC struct. We can't use the notion of a graph root 
* identifying the RPC struct because of potential references to the RPC
* struct EII (which would make it a non graph root).

To satisfy (v) we have a couple of options:

* (a) Implicit identification. Explicitly disallow "top level"
* non-serialization-root multirefs.  This will result in there being
* only a single child EII in the body, that EII being the RPC struct.
* [see below for why I don't think there is dependency between this and
* any particular school of thought about encodingStyle]

(b) Explicit identification. Introduce a means of identifying the EII 
that represents the RPC struct. There are a couple of ways that spring 
to mind that would allow us to do this:

*     1. Some form of tagging - e.g. the SOAP 1.1 root attribute. This 
* requires a change to the data model to introduce the concept of
* "serialization root" (not graph root as this is already implicit) so
* that the encoding can generate suitable mark-up during serialisation
* and that the RPC section can say that the RPC root is the only
* serialization root in the Body.

    2. Positional - e.g. first EII in the body is the RPC struct
=======================================================


 Why I believe there is no dependency between option a and
any particular school of thought about encodingStyle:
 RPC says that the SOAP Body carries exactly one struct (or array) in
the SOAP Data Model. (No box-carring.) Without top-level
non-serialization-root elements in the Body, there can be only one
element in a SOAP Data Model encoding, no matter the scoping of
encodingStyle.

                   Jacek Kopecky

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



On Wed, 8 May 2002, Marc Hadley wrote:

 > I'd like to summarise where we are in discussing root, top-level 
 > multi-refs and encodingStyle to see if we have reached any kind of 
 > useful conclusion.
 > 
 > Scope of encodingStyle AII
 > ==========================
 > 
 > There seems to a few schools of thought:
 > 
 > (i) encodingStyle should operate something along the lines of xmlns or 
 > xml:base. E.g. you can put it on the Envelope EII and it will apply to 
 > the contents of the Body EII and all header blocks but not to the SOAP 
 > envelope structures themselves.
 > 
 > (ii) encodingStyle applies to descendents of the EII it is placed on. 
 > E.g. you can put it on the Body EII and it applies to the contents of 
 > the body (but not the Body EII itself).
 > 
 > (iii) encodingStyle applies to the EII it is placed on and that EIIs 
 > descendants. E.g. you couldn't place it on the Body EII, but you could 
 > use it on child EIIs of the Body EII.
 > 
 > An open question exists regarding encoding refs between EIIs scoped by 
 > different values of encodingStyle. E.g. what does it mean to refer to an 
 > EII in an RDF graph from an EII in the SOAP encoding ?
 > 
 > 
 > Roots and top-level multi-refs
 > ==============================
 > 
 > I think there is general agreement to the following:
 > 
 > (i) Graph roots are graph nodes with no inbound edges.
 > (ii) ids and refs are scoped to the envelope rather than the body or a 
 > particular header block.
 > (iii) Cross-block (header->header, header->body, body->header) refs 
 > result in two otherwise separate graphs becoming a single graph.
 > (iv) The current encoding does not forbid top-level multi-refs, it just 
 > doesn't describe them. Developers new to SOAP 1.2 would be unlikely to 
 > produce software that generated top-level muti-refs, but migration from 
 > existing SOAP 1.1 codebases may produce software that generates 
 > top-level multi-refs.
 > (v) When using the RPC convention we need a way of identifying the EII 
 > that represents the RPC struct. We can't use the notion of a graph root 
 > identifying the RPC struct because of potential cross-block references 
 > (see (iii)) to the RPC struct EII (which would make it a non graph root).
 > 
 > To satisfy (v) we have a couple of options:
 > 
 > (a) Implicit identification. Explicitly disallow "top level" multirefs. 
 > This will result in there being only a single child EII in the body, 
 > that EII being the RPC struct. This seems to require encodingStyle 
 > school of thought (see top of message) (a) or (b), i.e. that the 
 > encodingStyle is in scope for the whole of the body, otherwise it would 
 > be legal to have multiple separate graphs in the body, each with their 
 > own encodingStyle.
 > 
 > (b) Explicit identification. Introduce a means of identifying the EII 
 > that represents the RPC struct. There are a couple of ways that spring 
 > to mind that would allow us to do this:
 > 
 >     1. Some form of tagging - e.g. the SOAP 1.1 root attribute. This 
 > requires a change to the data model to introduce the concept of "RPC 
 > root" (not graph root as this is already implicit) so that the encoding 
 > can generate suitable mark-up during serialisation and that the "RPC 
 > root" property is available in the graph following deserialisation.
 > 
 >     2. Positional - e.g. first EII in the body is the RPC struct
 > 
 > In summary I don't think we have yet come to any real conclusion, but 
 > hopefully I have captured the options available and noted any 
 > dependencies between them.
 > 
 > Regards,
 > Marc.
 > 
 >

Received on Thursday, 9 May 2002 10:20:13 UTC