W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: XML InfoSet and property value preservation

From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
Date: Thu, 17 Nov 2005 15:16:09 -0800
Message-Id: <F42A9895-BDC9-46EE-97E1-79D841C297DE@wsanchez.net>
Cc: Lukas Mathis <lukas.mathis@numcom.com>, WebDav <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

   OK, my concern is that I'm going to want to use any compliant XML  
library to read and write my XML by asking my library to read the XML  
and then telling it to render the property elements back out.  I'd  
really like to avoid having to know much more about XML than that, as  
you've noticed.  ;-)

   If you want me to preserve the prefixes, I'm worried that I would  
then have to choose an XML library that's "WebDAV compliant" (XML  
plus X) rather than simply XML compliant, or write my own XML  
generator.  (You're right that the prefixes are available at parse  
time in both SAX and DOM, so the issue in this case in the XML  
renderer.)  That's a lot more work for the server author as compared  
to the client simply escaping the XML so as to guarantee that the  
server gives you back exactly what you gave it.

   What value is there in the server doing any parsing of dead  
properties in the first place?  I still see no good reason to give  
the server XML (which it *has to* parse, because it's part of the  
containing request document) in a dead property.  I realize that we  
allow it today, and can't take that away, but why go through hoops  
preserve XML data on the server when the client can very easily  
guarantee it by sending the XML as CDATA instead?


On Nov 17, 2005, at 1:14 PM, Julian Reschke wrote:

> No, it's not a bug. There is no standard whatsoever about what an  
> XML API needs to provide. I even wrote a similar one for Java myself.
> But that doesn't mean that "generally", APIs do not provide this  
> kind of information.
Received on Thursday, 17 November 2005 23:16:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC