Issue 169: Forward References in SOAP Encoding

Issue 169

Issue 18 raised two questions - (a) where is the top level of the graph? (b) should multi-reference values be independent or embedded elements. Jacek opened a discussion on SOAP builders and summarized the results [2] on Oct 19th. During this discussion, three additional points were raised. Of them one is "maybe we should also disallow forward references". In this e-mail, I dwelled into the details on forward references. This is issue 169 [3].

[Argument 1] Forward References are Necessary

There are two claims. (A) Forward references are necessary in graphs that have loops and (B) Necessary for things like XMLDSIG.

For (A), Jacek proved very nicely that it is not necessary [4] and it is only a luxury. For (B), XMLDSIG does not use forward references from SOAP Encoding and there is no requirement from XMLDSIG that they depend on forward references in SOAP Encoding. This is a false claim.

[Argument 2] Forward References make life easier for Writers

The substance in this argument is, in the absence of forward references, then Writers will have to use a two pass model to walk thru a graph of values. But, in reality, regardless of forward references, Writers have to use a two pass model: first pass to compute multi-references and a second pass to compute the wire representation.

[Argument 3] Forward References do not impact Readers

There are claims that forward references do not impact Readers. Here is a little background on this. I opened another issue on the id and href mechanism used for multi-references, issue 163 [5]. Per 163, this id is not a real XML ID. That means, a generic XML processor, XPath processor or XPointer processor will not help you resolve these ids. Readers have to resolve these ids themselves. This leaves them in the cold.

In the presence of forward references, Readers are forced to adopt a two pass model to walk thru a SOAP message: first pass to compute ID-IDREF table and a second pass to compute the original graph of values. In the absence of forward references, Readers can adopt an efficient one pass model to walk thru a SOAP message. In this approach, a Reader can compute ID-IDREF table as it walks thru a SOAP message.

YES, forward references definitely impact Readers. In the absence of forward references, Readers benefit using a single pass model to compute the original graph of values.

[Argument 4] Rule out forward references thru out-of-band mechanisms

Well, yeah, forward references impact Readers. May be, you can rule out forward references thru private party agreements. Requirement 505 [6] rules out this statement, "The specification must be suitable for use between communicating parties that do not have a priori knowledge of each other"

[Argument 5] Breaks backward compatibility

Forbidding forward references in SOAP Encoding breaks backward compatibility. Lets step back and analyze this one.

Per issue 29 [7], SOAP offers pluggable data model and encoding rules framework. That means, it is possible to plug in a new data model and encoding rules at ease. This is the solution offered for RDF and XMI folks. This is also the solution adopted by SOAP 1.2 It uses a new encodingStyle -  http://www.w3.org/2001/09/soap-encoding - and indirectly introduced a new data model and encoding rules. This encodingStyle does not interfere with SOAP 1.1 encoding, http://schemas.xmlsoap.org/encoding/

And, nothing stops an application to use SOAP 1.1 encoding in a SOAP 1.2 message. 'Cos, it is pluggable. Hence, it DOES NOT break backward compatibility.

[Argument 6] Makes a big difference to Readers

YES, absence of forward references in SOAP Encoding makes a big difference to Readers. Readers can adopt an efficient one pass model rather than a two pass model. This makes a significant difference in resource constrained devices and for processing big SOAP messages.

AND, absence of forward references in SOAP Encoding satisfies one of the requirements and use cases - R309 and S21. In the latter use case, app does not have access to a DOM model of the data and data is available incrementally.

Requirement R309 [8] states that "XMLP should support applications that operate on resource constrained devices"

Usage Scenario S21 [9] states that "An XMLP sender generates a lengthy XMLP message that is incrementally transmitted and received by an XMLP receiver. The XMLP receiver employs an XMLP handler that can incrementally process the body as it is received (e.g., employing a SAX-style XML parser on the body as it arrives). Note that the entire message need not be present at one time at any point in its existence. 
This would be particularly helpful for memory-limited processors. It is also very efficient for services which are consistent with incremental, real-time transformations of the data, direct archiving of received data, etc. It would also be useful in scenarios in which voluminous body data can be directly transduced into application data structures or events by an XMLP (module) processor. In particular, there is no need for the explicit construction of a DOM model of the data. Support for XMLP data models might still be possible even with incremental processing if the models are incrementally constructible"

Request to the WG

If these reasons and arguments are compelling, I request this WG to rule out forward references in SOAP Encoding.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x18
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0231.html
[3] http://www.w3.org/2000/xp/Group/xmlp-issues#x169
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0326.html
[5] http://www.w3.org/2000/xp/Group/xmlp-issues#x163
[6] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#z505
[7] http://www.w3.org/2000/xp/Group/xmlp-issues#x29
[8] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#z309
[9] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#S21

Regards,

Asir S Vedamuthu

webMethods, Inc.
703-460-2513 or asirv@webmethods.com
http://www.webmethods.com/