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

 Marc,
 if not disagreed, then I at least clarified the intent I think.
I don't want to introduce RPC terms into the Data Model (like RPC
root), also I think your terminology was confusing (at least it 
confused me about the intent).
 Best regards,
 

                   Jacek Kopecky

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



On Thu, 9 May 2002, Marc Hadley wrote:

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

Received on Thursday, 9 May 2002 11:12:12 UTC