A. Pagaltzis wrote: > * David Powell <[EMAIL PROTECTED]> [2006-04-13 00:15]: >> This seems to be the wrong priority to me. > > Convincing arguments, IMHO; +1. >
Sorry, not convinced. I never once claimed that the motivation for using link was because it "looked" better. 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.... especially when the Atom spec expressly *allows* for such extensions. >[snip] > And, as regards David’s stance, I think it warrants a reminder > that `thr:in-reply-to` started life as as an `in-reply-to` link > relation as well, but we moved away from that because all of our > attempts to twist Atom links into carrying all the additional > semantics we needed ended up looking funny. > > So I would argue that the same appears to be a good idea for the > `replies` relation since it grew beyond the scope of Atom links. > 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"]. Big difference in this case. There are no additional semantics that make the replies link "look funny". It *looks* like a link; smells like a link; acts like a link; it *is* a link. The fact that that link MIGHT have two additional pieces of metadata associated with it does not make it any less of a link. Further, there is likely zero chance that properly coded rfc4287 implementations will do the Wrong Thing with a [EMAIL PROTECTED]"replies"], even if those implementations do choose to ignore-and-discard unknown foreign markup that happens to appear in the link. > I would even argue that what we are seeing here are really the > first observed instances of a general best practice pattern for > Atom extensions: > > > Trying to extend `atom:link` is bad. If you need more > semantics than afforded to it by RFC 4287, you should > clone it and tweak the copy. > > 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). The Atom link element is well defined and does *everything* the replies link requires, right on down to the undefinedAttribute* and the definition of "unknown foreign markup". 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. - James
