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

 Stuart,
 I was always thinking about the SOAP Encoding (as opposed to
general linking mechanisms and dereferencing).
 Your two issues are the right split of what was discussed here.
The issue #170 is your b). The resolution to a) may affect our
view of how b) should be resolved, though, I think.
 Anyway, since we are in the limited scope of defining the SOAP
Encoding, you seem to tend to agree with the MUST fault, right?
 As for scenarios for external references in serializations, we
can imagine the graph contained an array of bytes where a JPEG
image is stored. It might be useful to send this array as a
reference to an external file. However, I don't think putting
this functionality above core SOAP Encoding would really hurt
anybody (except for some recoding, of course).
 In Systinet, we ourselves use attachments which in their current
version depend on external hrefs, so I know what I'm talking
about when I'm saying that removing external linking capabilities
from SOAP Encoding would not really hurt because it can be done
in a different, more layered and therefore cleaner way.
 Btw, implementation of SOAP Encoding would be much simpler.
 Best regards,

                   Jacek Kopecky

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



On Fri, 4 Jan 2002, Williams, Stuart wrote:

 > Hi Jacek,
 >
 > Dare I ask whether there are two issues here?
 >
 >  a) The way in which references are made (URIrefs, IDREFs...)
 >  b) What happens when such a reference cannot be resolved and/or
 > dereferenced at a given SOAP Node.
 >
 > I think I have been thinking more generally about the
 > resolution/dereferencing of URIrefs carried by href attributes and have not
 > restricted my thinking solely to the context of the SOAP Encoding Style.
 >
 > Having looked more carefully at the current WDs (part 2 section 4.1 [1]) the
 > use of href and id attributes is more narrowly scoped than in earlier
 > versions. In earlier versions href and id were defined independent of
 > encoding style [2,3]. In our current WDs, the signifcance of unqualified
 > href and id attributes is undefined outside of their use in the SOAP
 > encoding style (I think).
 >
 > I guess that in terms of the SOAP Data Model and Encoding style I find it
 > difficult to conceive of a situation where serialising a graph conforming to
 > the data model would give rise to a reference that was not simply a
 > reference to a fragment within the same envelope. I suppose that it is
 > possible that an graph could be serialised into multiple entities (eg an
 > SOAP Message and some accompanying XML fragments carried in an attachment or
 > dumped to some web accessible resource and referenced by a graph edge
 > carring a full URIref...) - maybe I need to get further out of the box :-).
 >
 > 	Do folks actually want to do this (scatter a graph
 > 	across multiple messages/attachments/documents)?
 >
 > 	Or is it a "should not preclude"?
 >
 > 	Or is the case that in *all* practical cases of serialising
 > 	a graph conforming to the SOAP data model using the SOAP
 > 	encoding style, any references generated can be made as URIRefs
 > 	that contains just a fragment ID?
 >
 > If the latter then it does seem that IDREFs would, as others have suggested,
 > serve the purpose - I would like to understand better the reasons why others
 > feel strongly that the use of IDREFS would be a mistake (in the narrow
 > context of the SOAP encoding style).
 >
 > > And as for not knowing whether the server faulted because the
 > > server is only required to generate the fault and not to send it,
 > > this should be taken care of by the used message exchange
 > > pattern, like in request/response the fault is a response and a
 > > lack of response indicates some kind of failure.
 >
 > The point I was trying to make here, perhaps not very clearly, was that the
 > point in time where a reference is actually used (and the brokeness of the
 > reference discovered) may be well separated in time from the message
 > exchange that communicated the reference. eg a void function that normally
 > returns no result and where the computation simply gets queued for later.
 > There may be no existing message exchange context with which to associate
 > the fault. That said, this thinking about the more general use of hrefs (or
 > URIRefs, however communciated) than their use in SOAP encoding.
 >
 > However... regardless of the URIref/IDREF choice (which most of the above is
 > about)... what should be the correct behaviour when there is an (internal)
 > reference to a fragment (graph node) that has, for whatever reason gone
 > missing?
 >
 > In the context of deserialisation of the SOAP Encoding this feels like a
 > deserialisation failure (predicated on the assumption that the completed
 > graph serialisation is contained within a single message) - so that does
 > feel like it warrants a fault!
 >
 > In the more general context of dereferencing a URIRef (either because it is
 > a value at a graph node, or in some context other than SOAP encoding)...
 > that seems more like application semantic and mandating a fault seems overly
 > prescriptive.
 >
 > Regards
 >
 > Stuart
 > [1] http://www.w3.org/TR/2001/WD-soap12-part2-20011217/#encrules
 > [2] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/#reltoxml
 > [3] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#reltoxml
 > [4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x170
 >

Received on Friday, 4 January 2002 11:34:36 UTC