- From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Date: Tue, 3 Feb 2004 12:22:20 -0500
- To: "Williams, Stuart" <skw@hp.com>
- Cc: "'www-tag@w3.org'" <www-tag@w3.org>
At 3:21 PM +0000 2/3/04, Williams, Stuart wrote: >There seems to be some question as to whether xml:lang (and maybe xml:base) >survive the canonicalisation process. See [1] and thread. > I don't think there are any questions about this. If I recall correctly, they don't unless they're a part of the canonicalized chunk in which case they do. Perhaps what's being asked is really whether canonicalization invented the right semantics for equality. Personally, I suspect no one notion of deep equality will satisfy everyone. For instance, in my XOM work I do test base URIs for equality (which XML canonicalization does not) but consider two bases to be equal if one might be a relative form of the other. That's necessary for my unit tests to work, but it may well be not what everyone needs all the time. Similarly I compare document type declarations when comparing documents, which canonicalization doesn't do. I don't think the xml:lang and xml:base cases are particularly special. As long as you have less than a complete document being singed, there could always be ancestor attributes that have meaning in a particular local context and which are not signed. For instance, imagine a process which uses verified, approved, or confirmed attributes to describe the content of an element. If the elements descendants are signed without their ancestor it would be easy to change any of these from false to true or vice versa. I'm sure you can conceive of many similar cases. I don't think the predefined semantics of xml:base and xml:lang are so special that they are justified in being treated in a different way than any other attribute. -- Elliotte Rusty Harold elharo@metalab.unc.edu Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Received on Tuesday, 3 February 2004 12:29:16 UTC