RE: Proposed resolution: issues 78, 16

 Matt,
 I don't think this proposal does infer anything like you're
suggesting. This is a proposal for a solution that would be
completely independent of the data encoding used. Since data
encoding also covers referencing to other data (and how to write
multireferenced data), we tried to avoid touching that.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Wed, 1 Aug 2001, Matt Long wrote:

 > Does this proposal infer that distinctly different encodings and/or
 > symantics for multi-ref would  be applied to "rpc encoded" vs. "document
 > encoded" messages (and therefore the body of the rpc vs the headers of the
 > same message)?
 >
 > Thx,
 >
 > -Matt Long
 >
 >
 >
 > > -----Original Message-----
 > > From: xml-dist-app-request@w3.org
 > > [mailto:xml-dist-app-request@w3.org]On
 > > Behalf Of David Fallside
 > > Sent: Monday, July 30, 2001 5:05 PM
 > > To: xml-dist-app@w3.org
 > > Subject: 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/2001Ju
 > l/0139.html
 >
 >
 >
 > ............................................
 > David C. Fallside, IBM
 > Ext Ph: 530.477.7169
 > Int  Ph: 544.9665
 > fallside@us.ibm.com
 >

Received on Thursday, 2 August 2001 09:55:40 UTC