- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Fri, 9 Dec 2005 08:29:08 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org
- Message-ID: <OF489CA5FB.8DDE42A6-ON852570D2.004840D8-852570D2.0049FD60@us.ibm.com>
Julian wrote on 12/09/2005 05:01:36 AM: > > 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 string 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). Cheers, Geoff
Received on Friday, 9 December 2005 13:32:38 UTC