Re: Issue 169: Forward References in SOAP Encoding

 Asir, my response to some of your arguments:

Argument 1: I was talking about extensions _like_ XMLDSIG, not
XMLDSIG in particular, which turns out not to use Encoding
references. Extensions like XMLDSIG, should their architects
decide to build them on top of our Encoding, would IMHO find
forward references handy.

Argument 4: requirement 505 doesn't _require_ that the
communicating parties have no a priori knowledge of each other so
an out-of-band contract _may_ be used restrict SOAP Encoding.

Argument 5: the backwards compatibility breakage is meant in
terms of how much of the implementation will have to be changed
in order for it to support SOAP 1.2. Just changing the namespace
identifiers (and encodingStyle identifiers) is a small change,
forbidding forward references is a bigger change.

arguments 3 and 6: readers can use a single pass with forward
references as well and that quite easily, actually - when
encountering a forward reference, the client needs to keep a
pointer to where to put the data when it comes in. We do that in
our implementation and it works quite nicely. 8-)

As for requirement 309, it's not as though a constrained client
won't be able to parse any message with forward references, and
also it's not as though a constrained client will be able to
parse every message without forward references. 8-) But yes,
handling forward references can be an unnecessary burden.

Also the usage scenario 21 can be implemented even when fwd
references are allowed: if the sender cannot keep the whole
message in memory it will likely adopt the depth-first
serialization and it can serialize in a single pass even with
large data if it just generates (and remembers) IDs on every
value that can be referenced from more than one place. The
receiver can use the approach I showed in my reaction to your
arguments 3 and 6 and deserialize the huge message in one pass as
well.

All in all, I would not object to forbidding forward references
in our Encoding, I just don't see a compelling reason for doing
it.
                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 14 Nov 2001, Asir S Vedamuthu wrote:

 > 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/
 >

Received on Wednesday, 14 November 2001 11:00:22 UTC