A. Pagaltzis wrote:
> * James M Snell <[EMAIL PROTECTED]> [2006-05-20 06:40]:
>> A. Pagaltzis wrote:
>>> 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.
>
> How so? I honestly can’t follow that. Explain?
>
Two different things with the same name can lead to confusion... I
dunno, I guess it boils down to just a personal preference.
>[snip]
>> "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.
>
> Oh wait. I was bewildered because I read it as “Feed aggregators”
> rather than “Feed publishers.” Sorry! Comment retracted, the
> SHOULD is perfectly appropriate.
>
:-)
>[snip]
>> 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)
>
> That means it falls into the “compliance cannot reasonably be
> tested but non-compliance is likely to cause interop problems”
> bucket, which is exactly when a SHOULD is appropriate.
>
Ok, that's fine. SHOULD gets the point across.
>[snip]
> I dunno; it seems like a drop in the bucket compared to the rest
> of the spec, and if they’ve already implemented slash:comments
> semantics it seems like the effort to support an equivalent
> element in another extension is minimal.
>[snip]
>
> If they were previously already using it, sure. I’m willing to
> bet money that next to noone who implemented Atom 1.0 support
> from scratch is doing that, though. Rather, I’d posit that these
> are (nearly?) all template-based Atom 0.3 implementations that
> were upgraded to Atom 1.0 with minimum effort.
>
> I believe that those who come to Atom 1.0 with a clean slate
> benefit from the inclusion of a native atom:category element, and
> likewise those who come to the FTE with a clean slate will
> benefit from the inclusion of a native atom:entry Metadata
> element equivalent to slash:comments.
>
I wish I shared your optimism :-) ... if you want to draft up some text,
I'll include it.
- James
