Tim Bray wrote:
Draft format-04 says "Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12." If the element or attribute so labeled contains free text, xml:lang is relevant. If not, not. If you don't know (i.e. on some other-namespace exception), you'd better preserve it.
I'm not disputing your observations on the semantics of xml:lang, but I find that last sentence unacceptable and unrealistic in the context of the larger discussion on extensibility. I'll try to illustrate why.
Let's say a client generates the following Atom Entry Document to PUT at the server, which returns 204:
<entry xml:lang="en" xmlns="..." xmlns:ext="..."> ... <!-- a comment --> <updated xml:lang="de" ext:att="nein">time</updated> </entry>
I think we can all agree that it would be acceptable for a subsequent GET to return this:
<entry xml:lang="en" xmlns="..." xmlns:ext="...">...<updated xml:lang="de" ext:att="nein">time</updated></entry>
where the whitespace and comments are missing. So, not all aspects of the infoset must be preserved, nor must it be identical the original bytestream in the PUT. I think it should be acceptable to return the following:
<entry xml:lang="en" xmlns="...">...<updated>time</updated></entry>
This is why David (and myself) are pushing to define locations (head,entry,person) where extension content has special significance. Extensions would still be allowed at any location. However, if not located in one of the predefined locations, it could be discarded, because it's outside the "Atom model."
Robert Sayre
