Sorry for the delay in commenting, but I only got around to looking at this
in detail today.
Other than a few areas that I think need clarification in the wording, my
main problem with this proposal is the dereferenceable in-reply-to. While I
can see why a feed producer may want to include
I'm not a big fan of this either. The count can never be assured of any
accuracy so if I were to display something like this I end up having to try
and explain to my users why it says there are no replies when in fact they
there are 20.
Also, it forces excessive refreshes on the main feed
Hmm.. I think what this boils down to is a question about whether or not
the replies extension really does need to support replies to non-Atom
resources at all. I can see it both ways. I definitely understand
where you are coming from, but I also don't want to have to look in two
different
* James Holderness [EMAIL PROTECTED] [2005-10-27 16:40]:
I don't see how an Atom processor can do anything useful with
it (which couldn't be done just as easily with existing
elements). And if it's not of any use, it seems to be that it's
just taking up space and complicating the spec.
+1,
Ah crap, that's what I get for editing multiple docs at once. It's
supposed to be -01 and -02. I'll get that fixed. The -01 is the
current version; the new version waiting to publish has no significant
updates (just some minor typo stuff) so you should safely be able to
base your feedback
All,
At some point over the next couple of days, a slightly modified version
of the comments extension draft [1] will be published. The moment it
publishes will kick off a two week Unofficial Last Call period for the
spec. The spec has been stable of the past two months with no major
