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

[Bug 10] Round-tripping namespace decls in properties

From: <bugzilla@soe.ucsc.edu>
Date: Fri, 9 Dec 2005 02:06:14 -0800
Message-Id: <200512091006.jB9A6E4x004539@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10





------- Additional Comments From julian.reschke@greenbytes.de  2005-12-09 02:06 -------
Wilfredo,

thanks for the feedback. In our conference call, when we discussed this, 
the rational was that if we want server implementors to implement this 
at some point int the future, we need to tell them now. This is not 
extraordinary when upgrading specs.

More comments:

> I still maintain that it is unreasonable to require a server to preserve
namespace prefixes.  WebDAV 
> requires that server authors understand XML and XML namespaces.

That is correct.

> Adding requirements imposed by additional specifications (XSLT, etc.) puts an
undo burden on server 
> authors, given that some XML libraries, when asked to simply read XML into a
DOM and then render 

I think this is a misunderstanding. Preserving prefixes is not "imposed" 
by additional specifications. There was never any W3C spec that said 
that prefixes are irrelevant (or, if there is, please let me know).

> that XML *do* rewrite namespace prefixes.  If a server author can't simply ask
a library to render the 
> XML and instead has to dive into the innards of the library or write their own
renderer, you've obviated 
> the alleged value of using XML in the first place.  Dealing with XML in WebDAV
is hard enough as things 
> are.

Yes, and I confess that some years ago, I wrote a library in which I 
also deliberately threw away prefixes.

On the other hand, I really can't think of any W3C spec that licenses 
parsers or serializers to throw out prefix information. Server 
implementors will just have to make sure that the libraries they use 
work properly (just as for other less-well understood XML features).

> This is especially bothersome given that if a client cares about preserving
XML exactly as given, than a 
> simple encoding of the XML will guarantee that, and the server can remain
blissfully ignorant of that 
> content.  If you instead put the XML elements in a property, the server *has
to* parse them, and clients 
> should be willing to accept the consequenses of that.

Escaping XML so it becomes string data solves one problem, but creates 
lots of others (including weird display in generic clients, and 
surprising results in SEARCH requests). So I really don't buy in it 
being a proper solution to this problem in the generic case.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Friday, 9 December 2005 10:06:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT