RE: Proposal for issue 78: RPC structs and Encoding root attribute

The root attribute was added to deal with the ambiguity of independent
elements and headers under soap:Header elements. For example, consider
the following pseudo-Java:

FooHeader h1 = new FooHeader();
BarHeader h2 = new BarHeader();
PlainOldObject o = new PlainOldObject();
h1.poo = o;
h2.foo = h1;

SoapHeaders.Add(h1);
SoapHeaders.Add(h2);

The soap header element would look like this:

<s:Header>
  <ns1:FooHeader root="1" id="x">
    <poo href="#y" />
  </ns1:FooHeader>
  <ns2:PlainOldObject id="y" />
  <ns3:BarHeader id="z" root="1">
    <foo href="#x" />
  </ns3:BarHeader>
</s:Header>

The "root" attribute tells us which elements are "roots" and which are
simply subordinate marshals.

DB


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: Monday, February 18, 2002 8:56 PM
> To: xml-dist-app@w3.org
> Subject: Proposal for issue 78: RPC structs and Encoding root
attribute
> 
>  Hello all. 8-)
>  This message is intended for the Encoding task force, but please
> feel free to comment. 8-)
>  The issue 78 states that it is unclear which of the child
> element information items inside the SOAP Body is the RPC
> request/response struct, it also calls for clarification of the
> SOAP Encoding "root" attribute.
> 
>  For the RPC part:
>  Section 4.1 - RPC and SOAP Body [1] says that "the invocation is
> viewed as a single struct [...]", which, I think, is sufficient
> because the intent is that the Encoding rules will help us
> decide which of the element information items in the Body is the
> serialization root, as it is these rules alone who can cause
> other elements to be inside the Body.
> 
>  The Encoding part:
>  The section 3.7 - root Attribute information item [2]
> effectively says:
>  True serialization rules don't have the attribute, its value
> being implied as true. Elements that are not true roots can be
> labeled as such with root="true". Elements can explicitly be
> labeled as not being serialization roots with root="false".
> 
>  I am confused by the second statement. It means either that
> "elements that are not true roots can be labeled as not being
> true roots with root='true'" or "elements that are not true roots
> can be labeled as true roots with root='true'".
>  If it is the former, the meaning blends with that of
> root='false' and it should be that.
>  If the meaning is the latter, I can't see why a serialization
> non-root should ever be labeled as a serialization root. In any
> case, as a first possible solution I offer the following
> cleanups:
> 
>  1) Remove the namespace qualification of the root attribute
> information item (to go along with ref and id attribute IIs).
>  2) Rephrase the long paragraph into:
>  >>The root attribute information item can be used to label
> serialization roots that are not true roots of an object graph so
> that the object graph can be deserialized. True roots of a
> serialized graph have the implied value of "true" for this
> attribute information item or they may explicitly be labeled as
> true roots with a root attribute information item with a value of
> "true". An element information item that is not a serialization
> root but may appear so SHOULD/MUST explicitly be labeled as not
> being a serialization root with a root attribute information item
> with a value of "false".<<
> 
>  The second sentence of the rewrite consolidates the use of
> root="true" or omission of the attribute. The last sentence
> attempts to solve the RPC problem because if the serialization
> chose to put an element into an "independent" position as a child
> of the Body, it SHOULD/MUST mark this choice. The problem is the
> words "is not a root but may appear so" because it feels just too
> vague to be good.
> 
>  There is an other possible solution for issue 78: we have
> already removed the requirement that multiref nodes be put
> somewhere outside. I myself cannot see a reason why any
> application would want to put the elements as "independent" -
> maybe somebody enlightens me. As long as that does not happen, I
> don't see why we encourage or even mention such practice at all
> (the sole reason for section 3.7), therefore I suggest we remove
> the section and the root attribute information item.
>  If we do do so, IMHO we won't loose the only reason I can see
> for sticking multirefs out: to put some data shared between
> blocks (headers) inside a common block, which could simplify
> removal of various referrents to the shared data. For example:
> 
>  <env:Header>
>    <ns1:removeMe role="first" encStyle="soap-enc" ref="1"/>
>    <ns1:removeMe role="second" encStyle="soap-enc" ref="1"/>
>    <ns2:common role="../none">
>      <item encStyle="soap-enc" id="1"
>            xsi:type="xsd:int">42</item>
>    </ns2:common>
>  </env:Header>
> 
>  In such an application, the removal of one of the first two
> headers need not care about removing stuff that can be linked to
> from other blocks (because the particular application says so and
> takes care of that by forcing multirefs to be in the common
> header).
>  So then, IMHO when an application has a reason to stick
> multirefs out somewhere, it can make the somewhere's semantic
> deal with roots and non-roots and the explicit root attribute is
> unneeded. In RPC, for example no such sticking out is necessary
> (unless special extensions are in effect in which case the
> extensions themselves should take care of multirefs in their own
> ways like the above) so there would always be only one element in
> the Body and the RPC part is solved. 8-)
> 
>  If anyone gives me a good reason for keeping the root attribute,
> I'll suggest the first solution (the cleanups), until then I
> favor the removal (second solution) of enc:root.
> 
>  Sorry about making it this long, I just can't write otherwise...
>  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> [1]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#b1b2b6b8c20
> [2]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#b1b2b6b6c28
> 
>

Received on Thursday, 28 February 2002 12:57:18 UTC