Le Samedi 20 Mai 2006 04:21, A. Pagaltzis a écrit :
>
> Hi James,
>
> * James M Snell <[EMAIL PROTECTED]> [2006-05-19 20:00]:
> > Considerations for using thr:count and thr:when
>
> I’d still like thr:when called thr:updated, as it follows the
> same semantics as atom:updated and its value is of the same type.
+1
>
> > That is, the actual total number of responses contained by the
> > linked resource MAY differ than the number specified in the
> > thr:count attribute. Feed publishers SHOULD make an effort to
> > ensure that the meta is accurate.
>
> This SHOULD seems way too prescriptive. If you keep this sentence
> at all, I suggest changing to an informal “may want to.”
>
> > Feed publishers MUST consider a change to the thr:count and
> > thr:when attributes to be an "insignificant" update, meaning
> > that the value of the containing feed, entry or source
> > element's atom:updated element MUST NOT be affected by a change
> > to the values of either of these attributes.
>
> I would clarify this “an "insignificant" update in terms of RFC
> 4287”. However, I am not sure what this MUST buys, and more
> importantly, how it could be enforced. Suggesting SHOULD instead.
>
> > Lastly, implementors need to be aware that while the Atom
> > specification <xref target="RFC4287" /> explicitly allows the
> > link element to contain arbitrary extensions, the specification
> > does not require that implementations support such extensions.
>
> This concern could be partially addressed by including an element
> to specify a global reply count for an entry in an atom:entry
> Metadata element. The cost of such an inclusion is insignificant,
> and there are benefits for all consumers, including those which
> can support the namespaced link attributes. I strongly suggest
> adding such an element.
>
> I am willing to draft spec language for it if you want me to.
>
> > The element is not unlike the references and in-reply-to email message
> > headers defined by <xref target="RFC2822" />, with the exception that,
> > unlike those headers, the "in-reply-to" element is required only to
> > identify the unique identifier of a single parent resource as opposed to
> > the listing all of the unique identifiers for each preceding resource in
> > the thread. If the entry is a response to multiple resources,
> > additional "in-reply-to" elements MAY be used.
>
> This is an inaccurate description of the RFC 2822 headers.
> Suggest the following:
>
> The element is not unlike the references and in-reply-to
> email message headers defined by <xref target="RFC2822" />.
> However, unlike the in-reply-to header, the "in-reply-to"
> element is required to identify the unique identifier of only
> a single parent resource. If the entry is a response to
> multiple resources, additional "in-reply-to" elements MAY be
> used. There is no direct equivalent to the references header,
> which lists the unique identifiers of each preceding message
> in a thread.
>
> > If the resource being responded to does not have a persistent,
> > universally unique identifier, the IRI used to retrieve a
> > representation of the resource MAY be used so long as that IRI
> > could also be used as a valid atom:id value and so long as the
> > "href" attribute is also specified.
>
> It would improve interop if multiple disparate publishers
> publishing a response to the same resource were led to pick the
> same identifier, so I suggest changing this MAY to SHOULD.
>
> Regards,
