* James M Snell <[EMAIL PROTECTED]> [2006-04-13 04:10]: > What I did claim was that there is little to no technical > justification for exactly duplicating the link element for the > sole purpose of introducing two new optional attributes...
David countered that having this information is clearly useful, else these attributes would not be in the spec, which means there is a case to be made for making sure they’re available to all clients, even those behind an API that only provides access to Sec.6 extensions. > With in-reply-to, the key issue that swung the argument in > favor of a new extension element was whether or not the > [EMAIL PROTECTED] attribute value could be an atom:id value or > whether it had to be a dereferenceable URI. In other words, it > was quite likely that ignorant implementations would do the > Wrong Thing with a [EMAIL PROTECTED]"in-reply-to"]. My memory was different, so I went and re-read the threads. The non-dereferencable URI issue was an important sideline, but it was only a sideline in that discussion. If we were having that discussion now, I agree that it would be a much bigger sticking point, but back then, it was an also-ran. The big debate which swayed the issue at the time was having a mechanism for associating a source link with an in-reply-to link. We were trying all sorts of funny combinations with things nested inside the links or the links nested inside other things, IDREF attributes, and what have you. In the end, I put a big torch to my own proposition of an `in-reply-to` link relation to end the madness: http://www.imc.org/atom-syntax/mail-archive/msg16594.html > Big difference in this case. There are no additional semantics > that make the replies link "look funny". It’s not nearly as funny-looking as that crazy in-reply-to business we came up with back then, conceded. > Not to be snarky, but that philosophy hasn't exactly worked out > too well in the past (e.g. the rss 2.0 description tag). But `description` can only appear once in an item, and therefore there has to be some precedence matrix between it and its derivatives. Not so with `atom:link` and clones, all of which may appear any number of times in an entry, and thus pose no precedence problem. In other words, comparing the two situations is not quite fair. > Bottom line: I'd be far more inclined to either drop thr:when > and thr:count from the spec or document a clear caveat that the > two attributes are likely not to be supported in some > implementations than I would be to use anything other than link > for replies. Maybe we can think of other ways to expose this information so that it fits the Atom extension model? Are those attributes really the only possible approach to this issue? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
