Friday, March 24, 2006, 3:28:02 AM, James Snell wrote:
> I believe the concern is over the thr:count and thr:when attributes for > the replies link relation, both of which are optional, and both of which > provide what I consider to be extra information. In other words, it's > ok if an implementation drops them. Yeah I agree that an implementation losing those attributes wasn't exactly life-threatening. But is it "*ok* if an implementation drops them"? Will publishers think that it is ok if some infrastructure drop those attributes? Will subscribers? Presumably publishers have spent some effort adding those attributes to the feed, in the hope that subscribers will get some benefit from them. > The important bit is the in-reply-to element and the replies link > rel, both of which fall within the bounds of the Atom extension > model. Yeah, I agree. > I'm most certainly not abandoning the extension constructs. One of the > motivations for walking these extension specs through the I-D and > eventually standards-track process is so that they get their own RFC > number. Implementations that choose to support the extension can point > to RFC4287 *and* RFCwhatever and say, "I support both". If an > implementation only says "I support RFC4287" and doesn't say anything > about RFCwhatever, it's pretty clear what the result would be. > > The most an RFC4287 implementation should be expected to do is adhere to > the defined extension model. If that implementation also chooses to > support other RFC's that go beyond that extension model, so be it. I find much of section 6 of RFC4287 a bit pointless. It describes these classes of extensions, and I just think - so what?. I think it would be good to have a second draft which described a number of conformance levels for feed infrastructure - things like the handling, and preservation or not, of extensions. Then publishers would know that if a popular infrastructure (Windows RSS, Rome, Feedburner, APP implementations, etc) implements a given level of a compliance, what to expect. It isn't always preferable for a feed to reappear exactly as it was after travelling through an API or APP store, much of the added value in implementations will come from the transformations that they do. Even producing an archive feed, isn't possible without a reasonable number of transformations (eg: storing inherited constructs: author, base, lang, rights with the entry). > That said, the critical parts of the Feed Thread draft (the in-reply-to > element and the replies link rel) follow the guidelines of the Atom > extension model. That is, any RFC4287 implementation *should* be able > to do something with those elements (even if it's just preserving them). > The optional parts of the extension (thr:count an thr:when) fall > outside of the Atom extension model. That's ok. Implementations can > choose to ignore those things, even completely drop them. My hope is that implementors will be able to think of Atom in terms of Entries, Feeds, and everything else; rather than in terms of XML, a fragile document markup language. > As for the other extension drafts I put out, keep in mind that most > should be considered strictly experimental at this time. That said, > there is really only one that really falls outside the extension model.. > the Link Extensions draft [1]... which, by definition cannot adhere to > the extension model given the fact that Atom link elements are actually > not extensible. I haven't looked at them all thoroughly. Do you want to extend link elements rather than use extension elements in these cases because you expect that link constructs are more likely to provide a UI in implementations? I suppose that there are workarounds, eg: <feed> <ex:linkinfo href="http://www.example.org/mycommentsfeed.xml";> <ex:count>10</ex:count> <ex:when>2006-02-20T00:00:00Z</ex:when> </ex:linkinfo> <entry> <link rel="replies" type="application/atom+xml" href="http://www.example.org/mycommentsfeed.xml"; /> </entry> </feed> -- Dave
