Re: Clarification on use of encodingStyle attribute

 Dan,
 please see my responses inside. 8-)

                   Jacek Kopecky

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



On Thu, 21 Mar 2002, Dan Brickley wrote:

 > 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.

 I believe the spec does not give any implementation the licence
to merge any similar values. I don't see URIs as any different.  
The problem here lies with the notion of mutable vs. immutable
types. In Java, for example, all predefined basic types (Integer,
String etc.) are immutable (the value of the objects cannot 
change). In SOAP Encoding we're not saying any such thing and I 
think that's as much as we should say.
 If the values are mutable (and in many programming environments 
every value is mutable) and if the first URI undergoes some 
manipulation (like fragment id removal etc.) the other copies in 
possibly wholly different parts of the graph should not be 
affected, while the referencing copies should be. 
 Of course the application designer must be aware that some
environments with immutable simple types may automatically merge
references to equal values (before serialization or after
deserialization). And also these environments will not allow any 
manipulation on the referenced values, obviously.

 > (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).

Nice analogy, and IMHO it's true, too.

 > 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...

I think the balance should be "we'll make no inconsistent special
cases", and while in RDF a URI is very special, in general
applications two seemingly equal URIs need not necessarily be 
shared.

Best regards,

Jacek

Received on Monday, 25 March 2002 12:40:44 UTC