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 05:30:46 -0800
Message-Id: <200512091330.jB9DUk7D004894@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


------- Additional Comments From geoffrey.clemm@us.ibm.com  2005-12-09 05:30 -------
> > 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.

In addition, whatever body defined that property would have to very
clearly and very explicitly state that this property never
takes a top-level escaped string as a value, and that when an escaped
string is returned for that property value, the client should unescape the 
before processing the value.  Unless this is done, even non-generic
clients that are specifically written to understand that property will
fail to unescape the string (resulting in even more serious consequences
that for a generic client, since a generic client at least won't try to
do any significant processing of the value).

So escaping the XML is not something that a client writer can do to address
this problem ... it would have to be the property definer (and even then,
you are likely to get many clients that neglect to do the unescaping).

------- 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 13:31:14 UTC

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