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.
> 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,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
