Sunday, July 31, 2005, 4:47:44 PM, A. Pagaltzis wrote:
> Strictly speaking, per Extensions To the Atom Vocabulary (sec. > 6.2), an Atom processor must treat the nested link as it would > treat any other Structured Extension Element (sec. 6.4.2). Only child elements of atom:entry, atom:feed, and person constructs (and pending bugfixes: atom:source) can be Structured Extension Elements (Metadata Elements). Child elements of atom:link are not Metadata Elements, and neither are foreign-namespaced attributes; they are undefined markup. It might be possible to get away with using undefined markup to communicate between two consenting parties, but I don't think that it forms a viable platform for extension. It falls outside of the Atom model, and it can only be preserved between publishing client, publishing server, feed publication, and aggregator if all parties either have special case support for the extension, or they preserve the document's entire Infoset intact along every step in the chain. I don't believe that the latter is a realistic expectation for Atom implementations, so it seems reasonable behaviour for a publishing server to just drop undefined content, such as foreign-namespaced attributes and atom:link children, and to just publish the link without them. Personally, I read "undefined" more like how C uses the word undefined. -- Dave
