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

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 Wednesday, 8 May 2002 07:13:43 UTC