Proposed resolution: issues 78, 16

Posted on behalf of Frank DeRose
-----------------------------------


The RPCTF has been discussing solutions to issue 78. I have proposed one
solution to this issue [1]. Jacek has correctly pointed out one showstopper
problem with my proposed solution, namely, that it assumes that the term
"multi-ref element" is defined in Section 7. The term "multi-ref element"
is defined in the default encoding in Section 5. Thus, if Section 7 assumes
the definition of this term, a dependency is created between Section 7 and
Section 5. Such a dependency is undesirable.


In order to overcome this problem, the RPCTF is considering an alternative
solution. The rough outline of this solution is as follows:


1.) Define a new "rpc" namespace.


2.) The "rpc" namespace will have one optional attribute, called "start."
[As we flesh out the rpc convention, other attributes/elements may get
added to the "rpc" namespace. For example, it might be possible to add a
CorrelationId block to the "rpc" namespace.]


3.) The "start" attribute will be used on the SOAP Body element.


4.) If the "start" attribute is present on the Body element, its value is
the qualified name of the RPC element (request/response/fault) inside the
body. The purpose of the "start" attribute is to distinguish the starting
point of processing. This is similar to the way the "start" parameter in
the MIME multipart/related media type "points, via a Content-ID, to the
body part that contains the object root."


5.) If the "start" attribute is not present, it MUST be assumed that the
first syntactic element inside the body is the RPC element.


This solution has a couple of advantages:


1.) It makes it possible to know which element in the Body is the RPC
element without having to parse the entire Body first. [This was a
disadvantage of using the "root" attribute from Section 5.6.]


2.) It can be used with any encoding.


3.) It does not interfere with other RPC conventions currently in use,
since the "start" attribute would be defined only in the new "rpc"
namespace.


One problem with this solution is that it does not address the problem of
determining "serialization roots" inside the SOAP Header.


[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0139.html



............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com

Received on Monday, 30 July 2001 18:04:35 UTC