<grumble> ... I'm not really happy with it but this would work.
To be absolutely honest, David's comments here [1] really got me
thinking. It's definitely worth a read and alone was sufficient to sway
me on this. I don't like it; the use of the supplemental element is
ugly, but it's better than what's currently out there (e.g. slash:count)
and at the very least preserves the use case.
So this is what I've got:
count = element thr:count {
attribute xml:base { atomUri }?,
attribute ref { atomUri }?,
attribute updated { date-time }?,
( nonNegativeInteger )
}
The value of ref is the href of a replies link appearing in the
entry/feed/source. Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI. Publisher
would need to make sure that the href/ref combo match up properly, e.g.:
<link rel="replies"
href="comments"
xml:base="/06/04/21/blah/" />
<thr:count ref="comments"
xml:base="/06/04/21/blah/"
updated="...">5</thr:count>
The updated spec would have an appendix that would explain that previous
versions of the extension defined the attributes and that some
implementations have been deployed that use the attributes. The spec
will indicate that those attributes are deprecated in favor of the
thr:count element but that feed consumers have the discretion of whether
or not to support them.
Does this work?
- James
[1]http://www.oreillynet.com/xml/blog/2006/04/if_its_not_broken_dont_fix_it.html#comment-25193
A. Pagaltzis wrote:
>[snip]
> I’d instead propose a `thr:count` element with content, with
> attributes `ref` and `updated` (`when` is too vague, IMO; I’d
> prefer names suggestive of RFC4287 vernacular, particularly when
> the semantics are comparable). If `ref` is omitted, this is a
> global reply count. If it is present, this is a local reply count
> for that resource, and the content of the `ref` attribute must be
> identical with the `href` attribute of the corresponding link.
> `updated` is, of course, optional.
>
> A single global reply count is always permitted, in addition to
> local reply counts, of which there may be exactly one per
> resource referenced in a `replies` link.
>
> This reduces the typical use case to a single Simple Extension
> Element:
>
> <thr:count>5</thr:count>
>
> This accomodates developers with modest immediate needs neatly.
>
> The most complex scenario then looks something like this, where
> there are several additional Structured Extension Elements:
>
> <link rel="replies" href="http://example.org/06/04/21/blah/comments";
> type="application/atom+xml" />
> <link rel="replies" href="http://example.org/06/04/21/blah/trackbacks";
> type="application/atom+xml" />
> <thr:count ref="http://example.org/06/04/21/blah/comments";
> updated="2006-04-22T00:50:55+0200">4</thr:count>
> <thr:count ref="http://example.org/06/04/21/blah/trackbacks";
> updated="2006-04-21T22:21:37+0200">1</thr:count>
> <thr:count>5</thr:count>
>
> It’s somewhat ugly, but I think I can stomach it.
>
> How does that look?
>
> So far I’m not decided about whether there should be any language
> to suggest some interpretation of a discrepance between a global
> reply count and the sum of local reply counts, but I’m leaning
> strongly towards no. Since local reply counts would not have to
> be given for *every* resource, any constraint that the sum of
> local replies match up with global reply count would have to be
> qualified to apply only when local reply counts are present for
> *all* linked `replies` resources. So not only is it questionable
> whether such a constraint would really be useful in the first
> place, rather than an unnecessary burden, but it also would be
> complex, and yet feeble. That makes it seem like a bad idea.
>
>> d2:
>> <link rel="replies" href="..." />
>> <thr:replies count="..." when="..." />
>>
>> only one thr:replies would be specified regardless
>> of the number of replies links. count would be
>> reflective of the total number of known replies
>> across all links.
>
> -1. Having per-link information allows mapping scenarios more
> complex than the weblog model, such as a Usenet-ish landscape of
> multiple related, but independent distributed feeds. I’d rather
> not throw those out.
>
> Regards,
