W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

RE: Issue #170 proposal - referencing to missing data

From: Jacek Kopecky <jacek@systinet.com>
Date: Mon, 3 Dec 2001 18:47:14 +0100 (CET)
To: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0112031846530.18637-100000@mail.idoox.com>
 Nice simplification, Henrik, 8-)
 I just disagree with the fact that whether or not to dereference
the href attribute in SOAP Encoded data is dependent on
application semantics.
 If the application requires to be able to decide whether or not
to dereference some URI, the URI must be a value in the data
graph. IMO it's the SOAP Encoding processor that MUST handle SOAP
Encoding references.
 It is true though that the data wouldn't be deserialized (and
therefore references needn't be resolved) for example on a header
targeted at '.../none'.
 I'd keep the name UnresolvedReference because references that
the processor chooses not to attempt to resolve are not
necessarily bad.
 I agree that the part about detail should probably be skipped.
 So my next version would be:

 "The value of the href attribute is of type anyURI. If an href
value encountered during deserialization has a value that the
SOAP Encoding processor is incapable or unwilling for whatever
reason to dereference, a SOAP Fault MUST be generated with the
faultcode enc:UnresolvedReference."

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Mon, 3 Dec 2001, Henrik Frystyk Nielsen wrote:

 > I don't think this works. What if we have an optional header block using
 > the SOAP 1.2 encoding - does this mean that the receiver now MUST
 > resolve the references regardless of whether it wants to ignore the
 > block or not in order to be compliant? How is this possible to provide
 > test cases for and verify correctness?
 > In general, dealing with *any* part of a serialization depends on the
 > semantics of the parameters serialized but SOAP 1.2 has no understanding
 > of the semantics of application-defined data.
 > What we might want to consider is to provide a fault code that a SOAP
 > receiver can use IF the semantics of the encoded data calls for
 > dereferencing of an href and the data cannot be resolved.
 > Hmm, your proposal brings up another issue which is the use of that
 > "detail" element in that the proposed usage is not consistent with the
 > definition of how and when to use the detail element. I think in general
 > one needs more context as to why and when the reference could not be
 > resolved - I would tend to leave this to the application.
 > As a result I suggest rewording your proposal as follows:
 > "The value of the href attribute is of type anyURI. If the semantics of
 > the encoded data requires that an href value if dereferenced and the
 > SOAP Node is incapable for whatever reason to dereference the URI, a
 > SOAP Fault MUST be generated with the faultcode enc:BadReference."
 > Henrik Frystyk Nielsen
 > mailto:henrikn@microsoft.com
Received on Monday, 3 December 2001 12:47:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:17 UTC