On 5/17/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
- We're talking about visibility to implementations of the base spec only, not implementations of the extension, naturally. Any new information can be visible to implementations of that extension.
There's a misunderstanding here. Many applications rely on a feed parsing service provided by the OS or a language-level library. Some of those platforms (MS is not the only one) don't provide access to extension attributes on the link element. For example, <entry> ... <foo:bar /> <link foo:bar="baz" ... /> </entry> here the extension attribute stands a chance of getting lost. The reason this occurs is because it's much easier to design an API that doesn't deal with these things in the general case. This situation could change in the future, as Atom consumer APIs develop. My implementation will parse and preserve the attribute, but I'm not sure what I'm supposed to do with it at an application level, especially if I encounter more than one such link element. As a result, I see no reason to introduce gratuitous compatibility problems when the cardinality of the link element doesn't seem to suit the problem very well.
- We're talking about adding machine-parsable data that would be invisible to readers of the post content
I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. -- Robert Sayre
