W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Clarification on use of encodingStyle attribute

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 25 Mar 2002 12:40:45 -0500
To: Jacek Kopecky <jacek@systinet.com>
Cc: Dan Brickley <danbri@w3.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Martin Gudgin <marting@develop.com>, Herve Ruellan <ruellan@crf.canon.fr>, soap@zaks.demon.co.uk, xml-dist-app@w3.org
Message-ID: <OF088F9F36.28AA3895-ON85256B87.00626485@lotus.com>
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

 please see my responses inside. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

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 
 > 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 
 > stand for the thing that the URI names, and that a single URI string 
 > 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 
 > 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 
 > is analagous to the general XML notion of an Infoset, ie. the 
 > 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 
 > 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 
 > 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 

Best regards,

Received on Monday, 25 March 2002 16:52:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC