- From: Jacek Kopecky <jacek@idoox.com>
- Date: Thu, 9 Aug 2001 17:04:16 +0200 (CEST)
- To: Frank DeRose <frankd@tibco.com>
- cc: <xml-dist-app@w3.org>
Frank, thinking about it, this solution might be as good as the "encoding-independent with start attribute" one except for two points: 1) the whole body must be parsed in case of "root" attribute missing 2) some special implementations might want to choose not to implement the optional section-5 encoding, but they might like to implement RPC. You see, my point against the ties was that the actual RPC message would be different if the user used a different encoding. They can do that now as well except that the RPC element must be a section-5 encoded struct. Jacek Kopecky Idoox http://www.idoox.com/ On Wed, 8 Aug 2001, Frank DeRose wrote: > This email outlines what I believe to be the simplest solution to issues 78 > and 16. This solution corresponds roughly to solution "c" suggested by Noah. > Both Noah and Jacek are unhappy with this solution, but it is one logical > possibility, so we should consider it. It solves issues 78 and 16, it does > the least violence to the current spec, and it offers backwards > compatibility to a large number of current implementations. > > Briefly, this solution consists of 4 parts: > > 1.) Explicitly acknowledge that Section 7 MUST be used in conjunction with > Section 5. > 2.) Rewrite Section 5.6 to improve its clarity. > 3.) Rewrite the last paragraph of Section 7 to prohibit "boxcarring" and to > provide explicit instructions on how to handle RPC calls with 0 out params > and void return type. > 4.) Add definitions for RPC terms to glossary. > > I discuss each part in more detail below. > > 1.) Explicitly acknowledge that Section 7 MUST be used in conjunction with > Section 5. > Section 7 uses terms like "struct" and "accessor," which are defined in > Section 5. Consequently, Section 7 is implicitly dependent on the default > encoding defined in Section 5. Yet, Section 7 also states that it can be > used in conjunction with other encodings: > > "Although it is anticipated that this representation is likely to be used in > combination with the encoding style defined in section 5, other > representations are possible. The SOAP encodingStyle attribute (see section > 4.3.2) can be used to indicate the encoding style of the RPC invocation > and/or the response using the representation described in this section. > ... > As noted above, RPC invocation and response structs can be encoded according > to the rules in section 5, or other encodings can be specified using the > encodingStyle attribute (see section 4.1.1)." > > It is clearly a contradiction for Section 7 to be based on terms defined in > the default encoding and at the same time to state that other encoding > styles can be used. To eliminate this contradiction, we should delete the > two paragraphs quoted above and add the following text somewhere in Section > 7: > > <FranksVersion1ofRewriteToMakeSection7DependentOnSection5> > The RPC representation defined in section 7 MUST be used in conjunction with > the encoding style defined in Section 5. The use of an encoding style other > than the one defined in Section 5 MUST be interpreted to mean that an RPC > representation other than the one defined in Section 7 is being used. > </FranksVersion1ofRewriteToMakeSection7DependentOnSection5> > > 2.) Rewrite Section 5.6 to improve clarity. > Once Section 7 has been made explicitly dependent on Section 5, it becomes > possible to use the "root" attribute defined in Section 5.6 to distinguish > the serialization root in the Body of an RPC message from other elements > (such as multi-ref elements) that may also appear in the Body. I have > already proposed this rewrite of Section 5.6 in another email. I repeat it > here: > > <ProposedRewriteOfSection56> > The SOAP root attribute MAY be used to divide independent elements at the > same nesting level into 2 categories: those that are serialization roots and > those that are not. The purpose of marking an element as a serialization > root is to distinguish it as a starting point for 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." > > When not explicitly forbidden, there may be multiple serialization roots at > the same nesting level (for example, in the SOAP Header). > > The root attribute can have one of two values, "1" or "0". The value "1" > indicates that an element is a serialization root. The value "0" indicates > that an element is not a serialization root. The attribute does not have a > default value. All independent elements without the root attribute MUST be > assumed to be non-roots except in the case where no element has the root > attribute with a value of “1”. In that case, the first independent element > at that level without the root attribute MUST be considered to be the single > serialization root at that level. If no such element exists, it is an error. > </ProposedRewriteOfSection56> > A comment is in order on the "except" clause in the 5th sentence in the > third paragraph and the sentence that follows it in the proposed rewrite. > Some implementations have been using order to determine which element in the > body is the request/response element (in spite of the fact that SOAP 1.1 > doesn't provide any support for this). Namely, some implementations > interpret the first lexical element as the request/response element and all > subsequent elements as multi-reference elements, while others interpret the > last lexical element as the request/response element and all preceeding > elements as multi-reference elements. The "except" clause and the sentence > that follows are intended to provide backwards compatibility for the first > category of implementations. Unfortunately, AFAIK, there's no way to > accomodate both categories. > > I have attached a table of possible distributions of the root attribute on > various elements in a nesting level to demonstrate that the proposed rewrite > covers all possible cases. I ask members of the WG to examine this table > carefully to make sure I haven't made any errors or overlooked anything. > > 3.) Rewrite the last paragraph of Section 7 to prohibit boxcarring and to > provide explicit instructions for handling RPC calls with 0 out parameters > and void return type. > There seems to be general consensus among WG members that boxcarring ought > to be prohibited in the RPC representation defined in Section 7. There also > seems to be general consensus among WG members on how to handle RPC calls > with 0 out parameters and void return type. The consensus of the WG on these > two issues is summarized in the following rewrite of the last paragraph of > Section 7.1: > > <FranksVersion7OfSection71> > The Body of an RPC message MUST contain one and only one serialization root. > In the case of an RPC request message, this root is the RPC request element. > In the case of an RPC response message, this root is the RPC response > element (when the RPC succeeded) or an RPC fault element (when the RPC > failed). > > In the case of successful execution of an RPC with a void return type and no > [out] parameters, the Body of the RPC message MUST contain only the RPC > response element and that element MUST be empty. > </FranksVersion7OfSection71> > > 4.) Add definitions for RPC terms to glossary. > Members of the WG tend to use terms inconsistently when referring to RPC. > For example, the term "response" is used to refer to the entire SOAP message > (envelope), to the Body of the message, or to the element inside the Body > representing the out parameters. I propose that we add the following > definitions to the glossary and stick to them when discussing RPC. > > <FranksVersion3OfRPCTerms> > RPC message: a SOAP message (SOAP Envelope) containing an RPC request > element, an RPC response element, or an RPC fault element in its Body. > > RPC response message: a SOAP message (SOAP envelope) containing an RPC > response element or an RPC fault element in its Body. > > RPC request message: a SOAP message (SOAP Envelope) containing an RPC > request element in its Body. > > RPC element: inside the Body of an RPC message the serialization root that > represents the RPC request element, the RPC response element, or the RPC > fault element. > > RPC request element: inside the Body of an RPC request message the > serialization root that represents the [in] part of the RPC. > > RPC response element: inside the Body of an RPC response message the > serialization root that represents the [out] part of the RPC. > > RPC fault element: inside the Body of an RPC response message the > serialization root that consists of the SOAP Fault element resulting from an > RPC fault. > </FranksVersion3OfRPCTerms> > 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 > >
Received on Thursday, 9 August 2001 11:04:19 UTC