proposal for issue 391 (how IDREF URIs are dereferenced)

I was asked to provide a proposal for the resolution of LC issue #391 [1] directed
at the SOAP 1.2 Attachment Feature LC WD [2].

Issue description:

The SOAP encoding allows references by IDREFs inside the SOAP
envelope. A natural and common way to reference something on the Web
is to use a reference to a resource using an http: URI. The
Attachment Feature document suggests that such references are to be
handled by the Attachment Feature (example 3 in section 6).

It is unclear, with the current SOAP Version 1.2 specification, how
such URIs would be dereferenced, i.e. as part of the HTTP binding,   
by the SOAP processor, etc. Some clarity about this example is
desired.

Also, in such a case where the secondary parts do not travel along
with this message, the term "attachment" is awkward to talk about those
resources that need to be dereferenced.


Background/discussion:

Apart from the commentary, the submitter seems to be asking for two specific things: 

1. The submitter would like to have "clarity" on example 3 used in section 6 of [2] which states:
"The primary SOAP message part may be exchanged using the HTTP protocol binding without any further 
encapsulation and the JPEG image transmitted using a separate HTTP GET request."

I interpret "clarity" to mean that the submitter would like some description of the actual mechanism 
that is used to dereference the secondary part, which is referenced from within the SOAP message via a URI. 
IOW, should it be done as automatically as a part of the HTTP binding on receipt of an incoming message 
where the MEC is initialized to support the Attachment feature? Or is it left to the application be done 
at its discretion at some point afterwards?

Note that section 4 last para states: "The compound SOAP structure model does not require that a SOAP 
receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. 
It is up to the SOAP receiver to determine, based on the processing context provided by the primary 
SOAP message part, which operations must be performed (if any) on the secondary part(s)."

I believe this means that it is up to the application to resolve the external URI reference.

2. The second part of the submitter's proposal is discomfort with the use of the word "attachment" 
to refer to the secondary parts which do not travel with the primary SOAP message.

Note that section 3 "Terminology" and section 4 states that "secondary parts are [often] informally referred to as attachments." The only place where Attachment is used formally is the feature name.

PROPOSAL:

For item 1 above: I propose that we make a minor rewording for example 3 (<<new>> >>deleted<<) as follows:

"The primary SOAP message part may be exchanged using the HTTP protocol binding without any further 
encapsulation<<,>> and the JPEG image >>transmitted<< <<retrieved at the application's discretion>> using a 
separate HTTP GET request." 

For item 2 above, I propose that we decline to make any changes as there are sufficient caveats that
the word "attachment" is used informally, and no normative or formal text uses the word. The other informal
uses of the word, as a quick search of the text shows, are too trivial to cause confusion.

Thank you,
Nilo

 




[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x391
[2] http://www.w3.org/TR/2002/WD-soap12-af-20020924/