Re: RPCTF: Referencing Header items from Body

Frank,

To the particular question...

I don't see why it should matter whether a Body is an RPC or not with
respect to where it can get its data.  If it is an RPC, then you have
some conventions about how formal parameters might be represented, but
why should that preclude you from also referencing data elsewhere in
the envelope (by the same kinds of mechanisms that non-RPC processing
makes available)?  It is analogous to a subroutine having access both
to formal arguments and to global variables, external data in
databases, etc.

On a more general note...

It might be useful somewhere in the spec to specifically delineate the
types of information access that MUST be provided by an
implementation.  So far it seems like we have the following classes of
available data:

 * header entries
 * body entries
 * trailer elements
 * message data that accompanies the envelope,
   but is outside of it
   (e.g., in a SOAP with attachments type of scheme)
 * other external data

Perhaps a broader question is: Are there any real read/write access
constraints on any of this data in any context (intermediary, final
recipient, non-RPC, RPC, etc.)?  There are several aspects for
consideration:

(1) As you read the SOAP 1.1 spec, you get the feeling that there are
    some real constraints -- the header entries processed by an
    intermediary get removed, and new header entries can be inserted.
    The implication for me was that the SOAP processor API was going
    to strongly limit what an intermediary could do in manipulating
    the message.

    The current spec still has this language in section 4.2.2, but
    various use cases (encryption, compression, traceroute, etc.) have
    seemed to argue that applications need pretty much free rein to
    manipulate the message, even those parts targetted at other
    applications!!  (Such manipulation might be subject to constraints
    imposed by mustUnderstand, but it is still murky to me how message
    manipulation interacts with mustUnderstand.)

(2) We recently had a thread on use cases in which a node needed to
    manipulate a message even though no block in the message targeted it.

(3) Various access patterns have implications for those who might want
    to develop streaming implementations.  We haven't pointed out the
    conditions that would enable or be problematic for such implementations.

I do not think we have a very complete understanding yet of the
read/write access rules on message data.

--mark

   > From: "Frank DeRose" <frankd@tibco.com>
   > To: <xml-dist-app@w3.org>
   > Date: Mon, 23 Jul 2001 11:46:38 -0700
   > Subject: RPCTF: Referencing Header items from Body

   > The RPC Task Force (RPCTF) would like to gather input on the following set
   > of related questions:

   > Does the SOAP 1.2 spec allow Header items to be referenced from the Body?
   > Does the spec allow this under all circumstances or only when the Body is
   > not an RPC?
   > What is the meaning of Section 7.2 of the spec?
   > Does Section 7.2 need to be rewritten for clarity?

   > My personal interpretation of Section 7.2 is that it means that Header items
   > MUST NOT be referenced from the Body (at least when the Body is an RPC).
   > I've outlined in another email [1] why I interpret Section 7.2 this way.
   > Please read this email and Section 7.2 and provide input to the RPCTF on
   > these questions. Thanks.

   > Frank DeRose
   > TIBCO Software Inc.
   > 3165 Porter Dr
   > Palo Alto, CA 94303
   > 650-846-5570 (vox)
   > 650-846-1267 (fax)
   > frankd@tibco.com
   > www.tibco.com

   > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0163.html

Received on Tuesday, 24 July 2001 11:20:22 UTC