Re: Proposed resolution: issues 78, 16

Jacek,

As I mentioned, I was researching the constraints. I was
thinking about using something similar to what the XML Schema
schema for schemas schema used for selector and/or field
which constrains the xpath to be local to the current 
document.

Cheers,

Chris

Jacek Kopecky wrote:
> 
>  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:09:22 UTC