2006/4/13, James M Snell <[EMAIL PROTECTED]>:
> 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.

+1

> b. Drop thr:count and thr:when from the spec.

+0.5 (and let someone add that metadata later if needed, in the same
way as (a) or (d1) or maybe proposing something we haven't thought
about)

> c. Create a new replies extension element
>    <thr:replies href="..."
>                 type="..."
>                 hreflang="..."
>                 title="..."
>                 count="..."
>                 when="..." />

-0.5, it *is* a link

> 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, ugly
but that's probably what would better match today's approach (in "a" above)

>    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.

If I understand correctly, the use case for multiple "replies" link
is, e.g., having a "comments" and a "trackbacks/pingbacks" feeds
(could be distinguished by [EMAIL PROTECTED]). In this case, having a
@count per link is IMO somewhat important. So -1.

--
Thomas Broyer

Reply via email to