Re: Clarification on use of encodingStyle attribute

On Thu, 21 Mar 2002, Martin Gudgin wrote:

> I would also like the answers to these questions. My own feelings are as
> follows;
>
> 1    a single envelope can contain multiple disjoint graphs
>
> 2    If there are href/id connections between two header entries, they are a
> single graph
>
> 3    In light of 2 we probably need to spell out that graph nodes can be
> serialized in-line or out-of-line

A related question...

If two (separately serialized) nodes have a edge whose value is
XML-datatyped as an xsd:anyURI, with identical content (eg. perhaps a
common UUID or an HTTP URL), are we licensed to assume that the value
nodes denote the same thing? ie. could one parse and the reserialize the
merged graph using a single value node without information loss? If so,
this seems to somewhat duplicate the href/id machinery (probably not a
problem).

This is based on the assumption that nodes with URI content in some sense
stand for the thing that the URI names, and that a single URI string can't
reasonably be used as a name for two distinct resources (at least
within the context of the same XML message/document).

I want my SOAP-Encoding tools to be very careful about information loss
when parsing and reserializing this stuff, so advise on this point would
be much appreciated. I'm currently thinking that the semantics of
xsd:anyURI license me to merge nodes somehow, but I'm confused as to
whether this would be application-level versus spec-mandated behaviour.

(aside: it feels like we have a concept of a SOAP Encoding graph here that
is analagous to the general XML notion of an Infoset, ie. the information
content considered relevant by the Encoding spec versus the bits that
can be thrown out during processing).

Forcing SOAP 1.2 implementations to know about the meaning of each of the
XML Schema datatypes is imho too much to ask, yet URIs have a special
status in Web architecture, protocols and XML, so having the Encoding spec
acknowledge the meaning of xsd:anyURI strikes me as a reasonable design
option. Tricky balance...

Dan



-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Thursday, 21 March 2002 10:24:20 UTC