* James M Snell <[EMAIL PROTECTED]> [2006-04-13 09:05]:
> Maybe, but given that WG messed up in not making the link
> element formally extensible, it's not likely to be pretty.
Yes. WGs mess up. It’s just life. In a perfect world, this would
be different, but Atom took long enough to ship. What we shipped
feels very solid and robust to me, despite the occasional hole or
oversight.
So let’s just accept that what we have is somewhat imperfect, and
try to get as close to pretty as we can within the constraints.
> Also, keep in mind that the uglier and more complicated the
> "correct" approach looks, the more implementors are going to
> gravitate towards less-than-correct approaches that meet their
> immediate needs.
I know.
> a. Status quo. Leave things the way they are in the current
> draft with a firm warning to implementors that not all atom
> impls will be capable of supporting them.
-0.5. As David and Byrne pointed out, having this information is
clearly useful, otherwise these attributes would not be part of
the spec; so it’s worth making an effort to make them available.
> b. Drop thr:count and thr:when from the spec.
+0
Though -0.5 if that’s all that would happen. *Some* mechanism for
providing this information should be available.
> c. Create a new replies extension element
> <thr:replies href="..."
> type="..."
> hreflang="..."
> title="..."
> count="..."
> when="..." />
+0.5
> d. Create a supplemental extension element
>
> d1:
> <link rel="replies" href="..." />
> <thr:replies ref="..." count="..." when="..." />
>
> Where the ref attribute in <thr:replies /> is a
> unique identifier that can be matched to the
> resource linked by the replies link. If only a
> single replies link is specified, ref can be
> omitted. There could be one thr:replies for
> each replies link.
+0.5
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,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
