Re: Issue #170 proposal - referencing to missing data

I like the direction that this is taking, basically...

However, it does highlight the point I was making,
that from an encoding perspective, we expected that
all serialized data be local to the Envelope document
and that any marshalling that involved "external" URIs
should be treated as application semantics and be
separate from the serialization/deserialization semantics
and be treated in terms of a serialized value.

The only change that I might suggest w/r/t this last
suggestion would be to remove the "or unwilling..."

e.g.

"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 of dereferencing, a SOAP
Fault MUST be generated with the faultcode enc:UnresolvedReference."

Cheers,

Chris

Jacek Kopecky wrote:

>  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)
>                    http://www.systinet.com/
> 
> 
> 
> 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 13:01:10 UTC