- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Fri, 23 Dec 2005 10:33:46 -0500
- To: " webdav" <w3c-dist-auth@w3.org>
- Message-ID: <OF22561396.8311FF0A-ON852570E0.0051983D-852570E0.00557DAD@us.ibm.com>
Lisa wrote on 12/23/2005 09:42:01 AM: > Wilfredo points out something I hadn't considered before, which I think > addresses your concern, Geoff -- the idea that the only agents that > need to preserve prefixes are those that want to. My point below was that this is precisely what an agent cannot do (if by "agent", you mean an individual client). One agent cannot decide to preserve prefixes by escaping the XML for a given property value, unless *all* agents have agreed to do so (i.e., unless that property by definition always holds escaped XML text). So at a minimum, you can never use this approach for an existing property, because none of the existing clients will be escaping the property value on write or unescaping the property value on read. > - Currently we have no known servers or clients that have a need to > preserve prefixes. I'm not sure who "we" refers to here, but minimally it doesn't include us (:-), because we will store XML schema and XSLT data in property values, which do require that namespace tags be preserved. I doubt we're the only ones that will do so. > - If we had a server that decided to implement XPath-based search or > something similar, that server could unilaterally begin to preserve > prefixes as long as the standard doesn't prevent it. Alternatively, a server could unilaterally decide to not preserve prefixes, since the standard doesn't require it (i.e., it is not a MUST). > - If we had a client that decided to do something similar on its local > cache/copy of data, the client would have to get a prefix-preserving > parser and do a bunch of other work too -- but I don't see how the > server behavior would entirely prevent this from working. What prevents this from working (well) is that it could do so only if all other clients that read or wrote this property did so as well. This approach is likely to be a source of subtle interoperability problems. > So although I'm OK with saying SHOULD preserve, I see good arguments > for saying MAY preserve and I'm fine with that resolution too. I very rarely care about the distinction between SHOULD vs. MAY, and this is not one of those rare times (:-). Cheers, Geoff
Received on Friday, 23 December 2005 15:33:55 UTC