David Powell wrote: > 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. >
Yes, I think it's ok to drop them. In fact, I'll likely add something to the spec that discusses this issue.. specifically, that the thr:count and thr:when attributes fall outside of the atom extensibility model and may not be preserved by strictly compliant RFC4287 implementations. In other words, here they are, but use at your own risk. >[snip] >> 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 agree, but... > 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). > In my view of the current spec, Atom has two layers of extensibility. One layer is defined in section 6. The other is defined by XML. A strictly compliant RFC4287 implementation should only be expected to comply with section 6, but that doesn't mean the implementation cannot also support general extensibility on the XML layer. >[snip] > 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. > Yep. In the Atom implementation I've written, the entire XML infoset is preserved with an Atom object model layered over the top. E.g. code can work with Feed, Entry, Link, etc. As far as extensibility is concerned, that Atom object model only exposes section 6 extensions. If the app developer wants to look at things from an XML perspective, they can peel back a layer and work with the infoset directly. > 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 want to extend Link because there is little sense in reinventing it. It would be silly for me to have a <foo:link /> sitting side by side with <atom:link /> when both serve the same general purpose. It was a mistake not to make atom:link extensible per section 6. However, this is still XML and Atom allows undefined content and undefined attributes on atom:link, so, I'm free to do what I want with atom:link so long as I'm aware up front that what I'm doing falls outside the bounds of Atom's section 6 extensibility model. Personally, I think that folks will find in the long run that section 6 really is pointless. > 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> > Blech. :-) - James
