* James M Snell <[EMAIL PROTECTED]> [2005-08-09 07:25]: > The second feed illustrates the two forms of the in-reply-to > element. The dereferenceable form uses the href attribute to > locate the entity being responded to.
I am still strongly -1 on making the ID optional. Why do you want to do that? What scenario exists wherein it would be *more* desirable to provide *only* a dereferencable location but *not* an ID? When would it be *wiser* to *rely* on a pointer to a resource which is always in danger of voiding, irrecoverably breaking the connection from a reply to its parent? The ID is REQUIRED in Atom entries. Given this, is there any *cost* to requiring its inclusion when specifying in-reply-to? I can’t see any. To me, making the option available seems like requiring content producers to make a choice about something their consumers will never benefit from but may sometimes be harmed by – while burdening consumer implementors with an extra conditional to implement support for a useless option, and possibly requiring them to sometimes fetch representations over the network to even decide how to thread things. If you can give me just one example of a scenario where omitting the ID is beneficial, I’ll concede the point. Otherwise, I maintain that this is a mistake. Options have a cost. They should not be provided just for the sake of having them. And sorry that I keep bludgeoning you. :-) I hope you can see that my arguments are sound – or show me that they’re not. (After all, I was just as wrong during half the previous discussion…) > The nondereferenceable form uses a combination of a required id > attribute and an optional src attribute. I’d really like this to include an atom:[EMAIL PROTECTED]'related'] pointing to the source to encourage its provision. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
