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 Monday, 18 February 2002 15:56:08 UTC