Re: Proposed resolution: issues 78, 16

Jacek,

If the start attribute were defined as type xsd:anyURI, then
it could be an XPath expression which would provide
for both the case where an ID were present, as well
as for when one is unavailable.

	<S:Envelope xmlns:S="...">
		<S:Header ...>...</S:Header>
		<S:Body R:start="id(N12)" xmlns:R="...">
			<my:Foo xmlns:my="..." id="N12"/>
		</S:Body>
	</S:Envelope>

or equally in the absence of an XML ID attribute:

	<S:Envelope xmlns:S="...">
		<S:Header ...>...</S:Header>
		<S:Body R:start="//S:Body/my:Foo[1]" xmlns:R="...">
			<my:Foo xmlns:my="..."/>
		</S:Body>
	</S:Envelope>

There are potentially some interesting namespace issues that I'm
currently investigating, but it certainly provides for what you
are looking for below as well as addressing the problems that
you cite such as the case where more than one element share 
the same QName.

I tend to agree with Paul's comment in [1] that the start attribute
would be useful as applied to the SOAP Headers as well as the Body
as I indicated on the RPCTF con-call. Thus, a separate RPC 
namespace for this might be unnecessary. It would seem to me to
have sufficient usefulness as to belong in core SOAP and share the
SOAP envelope namespace.

Cheers,

Chris

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0367.html

Jacek Kopecky wrote:
> 
>  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 13:56:35 UTC