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

Out of curiousity, and following on Don's note, does the latest proposed 
text define serialization root in a way that capture the essence of Don's 
example?   I think users are as confused about what a root is as about how 
to label one once they've got one.  If we can't unambiguously define 
serialization root, then I'm suspicous of the whole feature (I suspect the 
feature is needed, I just want to set the bar high on having clear 
explanations.  If the explanation is ambiguous or circular, the feature 
will be used inconsistently, and interop will suffer anyway.)  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Don Box" <dbox@microsoft.com>
Sent by: xml-dist-app-request@w3.org
02/28/2002 12:55 PM

 
        To:     "Jacek Kopecky" <jacek@systinet.com>, <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        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 Saturday, 2 March 2002 14:27:42 UTC