A. Pagaltzis wrote:
> 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.
>
I'm still stewing over this and haven't quite made up my mind on it yet.
The only reason I'm not quite comfortable with it is that it just seems
confusing have both an atom:updated and a thr:updated.
>> 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.”
>
"may want to" is a little too weak for me, but yes, the SHOULD is too
much. Let me think about it. If I can't come up with something better,
I'll use the "may want to" suggestion.
>> 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.
>
Making this a MUST will (hopefully) reduce the likelihood false-updates
for clients that don't understand FTE. That is, if I use a client that
does not understand FTE and I suddenly see an entry that is marked as
updated for no apparent reason, I'm likely to get quite annoyed after a
while.
(note that I included this after running some tests on a couple of feed
readers and discovered that it is indeed quite annoying)
>> 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.
>
Yeah, I'm still stewing over this. I've started and stopped writing a
section for this about a dozen times over the last couple of days. On
the one hand, it makes a lot of sense for the spec to have this. On the
other, I could imagine feed reader implementors being quite pissed off
that they have to support an element with identical
form/function/semantics as slash:comments just so feed publishers can
avoid having to declare one additional xml namespace. Also consider
that even if FTE declares a <thr:count>5</thr:count> element, most folks
are likely going to keep on using slash:comments. (I mean, heck, look
at the number of Atom 1.0 feeds that are still using <dc:subject> to
indicate the category!!)
The other elements/attributes in FTE don't suffer from this problem
because they introduce useful new functionality/semantics while also
reducing the number of xml namespaces that need to be declared.
I dunno, I guess I'm not really against having the element; I'm just
having a hard time getting myself to define it.
>> 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.
>
Yeah, I got to thinking the same thing after I posted the note. Your
text is much better.
>> 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.
>
Good suggestion.
> Regards,
Thanks for taking a look
- James
