Issue #170: "Referencing Data missing from the message"

Discussion of issue #170 seems to have stalled without a final resolution. I
picked up an action on Wednesdays telcon to review recent discussion of this
issue with the intent to restart the discussion and reach a final
resolution.

Issue #170 [1] "Referencing data that can be stripped out from the message":
originates from a posting from Jacek [2] summarising soapbuilders discussion
of inlining multi-refs.

A summary and more detailed review of the discussion to date follows.

Best regards

Stuart Williams
--

In-Summary:
-----------
Issue #170 was largely resolved at the November F2F leaving Jacek with the
action to generate resolution text. 

The discussion and refinement of the resolution text appears to have stalled
at a point of possible difference between Jacek and Noah over whether a SOAP
fault MUST (Jacek) or MAY (Noah) be generated as a consequence of a failure
to resolve/dereference an href within a deserialised fragment of SOAP
encoding.

The difference may not be so strong, given that Jacek [16] is open to the
deserialisation process being lazy, avoiding the need to resolve/dereference
references that are not actually required by the computation at the local
SOAP node.

There may be a difference between Noah and Jacek on whether a SOAP Fault
*MUST* be generated in the event that href resolution/dereferencing during
deserialisation (lazy or otherwise) is actually made and fails. 

Henrik participated in the early part of the discussion and it is not clear
whether he has a strong view on the MAY/MUST question.

Resolving this MAY/MUST question will lead to the final closure of this
issue.


In-detail:
----------

The issue seems to have substantially resolved at the F2F [3] as follows:

[Extract from rough F2F minutes (yet to be approved by WG)]
> PROPOSAL : Accept (a) (don't change anything) and someone writes text
which
> clarifies:
> - You MUST resolve local refs
> - You MAY resolve other refs
> - Description of faults which references entail for consistency
>
> [NO DISSENT]
>
> ACTION ITEM : Jacek will write clarifying text for issue 170 resolution by
EOB
> Monday.

This resulted in an AI on Jacek to propose resolution text for Issue 170
which he as done[4]. 

This seems to have unravelled into further discussion on the thread at [4].

IMO this is issue is also closely related to Issue 168 [5] "Type of
referenced external data" in as much that the recent (monster) threads on
#168 contain substantial discussion on the nature of links within SOAP
encoding albeit that the focus of #168 is on the typing of things so
referenced.

Jacek's proposed resolution text [4] proposes that SOAP receivers MUST make
an attempt to resolve local references and MAY make an attempt to resolve
non-(document?) local references. Jacek also proposes the mandatory
generation of a SOAP fault in the circumstance that an attempted resolution
fails.

Henrik [5] questions whether we really want to mandate resolution of hrefs
particular in respect of blocks not targetted/processed at the current SOAP
node. More generally Henrik suggest that correct resolution and processing
of hrefs serialisde in the SOAP encodind depends upon applications semantics
about of which SOAP explicitly has no understanding. Henrik proposes
alternate text asserting that the actioning of href resolution and
associated dereferencing are determined by application semantic. Henrik
retains the mandatory generation of a SOAP Fault in the event that an
attempt is made to resolve and dereferene an href within the serialisation.

Jacek [6] acknowledges Henriks simplification, but disagrees that the
descision to resolve and dereference an href within a SOAP encodingStyle
fragment is wholly at the discretion of application semantics. Jacek refines
Henriks proposal at [5] by placing the emphasis of href
resolution/dereferencing on the deserialisation process rather than the
semantics of the data.

Chris Ferris [7] concurs with the direction the discussion is taking, but
reemphasises his expectation that serialised data arising from the
serialisation process will be local to the envelope and that marshalling of
external references should be regarded as having application semantics.
Suggest a tweak to the resolution text to remove the notion of unwillingness
to resolve/dereference an href and as distinguished (in the narrative)
reason for fault generation.

Mark Baker [8] makes an informational point that some care is required to be
clear that its is possible to dereference information held in caches without
necessarily having to use a network.

Henrik [9] and Jacek [10] concur with Mark.

Jean-Jacques [11] seeks clarification of references to headers target at
.../none in response to Jacek's eariler message [6].

Jacek [12] provides clarification to Jean-Jacques distinguishing between
graph deserialisation and header processing (ala processing model).

Noah [13] cautions some care in mandating the generation of faults may imply
or even require some constraint on the ordering of message processing. Noah
introduces 'weak references' into the discussion (message fragments that
whilst present do not effect the outcome of the computation due to the
presense of other message fragments - eg. lazy evaluation of a conditional).
Noah expresses support for Henriks earlier proposal (unreferenced but
presumably [5]) but suggesting that fault generation is MAY rather than
MUST.

Jacek [14,16] and Noah [15] discuss 'weak references'. Jacek [16] reasserts
MUST on fault generation in the event of an actual failure to
resolve/dereference an href.
-- 
[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x170
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0231.html
[3] http://www.w3.org/2000/xp/Group/1/11/f2f-minutes 
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0012.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0017.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0018.html
[7] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0020.html

[8] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0023.html
[9] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0024.html
[10] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0025.html

[11] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0032.html
[12] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0035.html

[13] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0047.html
[14] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0050.html
[15] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0107.html
[16] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0108.html

Received on Wednesday, 2 January 2002 04:15:39 UTC