Re: Proposed resolution: issues 78, 16

 Chris,
 I don't feel that having "start" attribute as anyURI would be a
good idea:
 1) it would indicate that you can actually refer to just about
anything in the web from the start attribute and this could get
dirty,
 2) you would either mandate or strongly suggest xpath support in
SOAP processors, which is not exactly a trivial thing to do,
 3) since the SOAP processor (and the underlying XML layer) is
the one that controls (or should control) ID values, I can't see
why an ID shouldn't be available.

 I actually also tend to agree that start attribute might be
useful outside of RPC and so it would probably be in the envelope
namespace. But please see my concerns with this in [1].

 Kind regards,


                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/

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



On Wed, 1 Aug 2001, christopher ferris wrote:

 > 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 Thursday, 2 August 2001 10:02:59 UTC