Re: Clarification on use of encodingStyle attribute

I agree with the spirit of Dan's response, but I would frame it a little 
differently.  The SOAP encoding specification describes a graph model, and 
the correspondence between serializations and graphs.  There is no 
question that multiple serializations of a value correspond to multiple 
nodes in the graph. 

The specification is silent on the possible representation of graph nodes 
in programming language structures.  Similarly, there is no update model 
for graphs once they are deserialized.  SOAP says nothing about what it 
would or would not mean to change the value of a node, once deserialized. 
The obvious way to go is that separate values, which correspond to 
separate nodes, result in either separate programming language structures, 
or to single structures with copy on write behavior.  Still, any such 
decision is beyond the scope of the SOAP encoding specification, IMO. 
Thank you.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jacek Kopecky <jacek@systinet.com>
03/25/2002 12:40 PM

 
        To:     Dan Brickley <danbri@w3.org>
        cc:     Martin Gudgin <marting@develop.com>, <noah_mendelsohn@us.ibm.com>, Herve 
Ruellan <ruellan@crf.canon.fr>, Henrik Frystyk Nielsen 
<henrikn@microsoft.com>, <soap@zaks.demon.co.uk>, <xml-dist-app@w3.org>
        Subject:        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 16:52:02 UTC