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

Jacek Kopecky wrote:

>  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):
> 

Actually I don't think we disagree much at all, see below.


> * 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.

 >
This bit isn't any different to my original.


> * (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).
> 

This bit also isn't any different.


> 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.

 >
You inserted the word(s) "non-serialization-root" - I don't think this 
changes the intent of my text.


> * [see below for why I don't think there is dependency between this and
> * any particular school of thought about encodingStyle]
> 

OK.


> (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.
> 

You changed "RPC root" to "serialization root", I think we mean the same 
thing. Your change to the final sentence seems to me to be saying the 
same thing as my original text in a different way, I don't think we 
disagree.


> 
>  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.
> 

I agree, I withdraw my assertion that there is a dependency.

Regards,
Marc.

> 
> 
> 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.
>  >  > 
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Thursday, 9 May 2002 10:58:53 UTC