Re: Proposed resolution: issues 78, 16

 Hi. 8-)
 Generally I agree with this solution very much. I only have a
few minor comments, see inside.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 31 Jul 2001, Frank DeRose wrote:

 >
 > In the next WG telcon, we'll be discussing issues 78 and
 > 16. The RPCTF has already begun 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."

 I'd prefer the rpc:start attribute's value to be a reference to
the ID of the rpc element, so the rpc:start attribute would be of
type IDREF. This "pointing" method is more XMLish and it allows
distinguishing among multiple elements with the same fqname.
 On the other hand, this would require us to standardize an ID
attribute (which I'd like to see anyway), and this ID attribute
could/should be in the SOAP core, something like SOAP-ENV:id.
(I'm using the prefixes SOAP-ENV: and rpc: for the envelope
namespace and the new soap-rpc namespace respectively).

 > 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.

But this is not a problem for the RPC TF because IMHO
serialization should be considered when we talk about the
encoding, which according to the current schedule would be after
the september f2f.


Jacek

Received on Wednesday, 1 August 2001 10:57:00 UTC