Saturday, April 22, 2006, 1:53:26 AM, James M Snell wrote:
> So this is what I've got:
> count = element thr:count {
> attribute xml:base { atomUri }?,
> attribute ref { atomUri }?,
> attribute updated { date-time }?,
> ( nonNegativeInteger )
> }
I think that is ok.
Aristotle's suggestion is ok, in that it saves a bit of typing in the
common case where there is only one link - but in the case where there
is more than one link, a combined count seems pretty useless: if there
are multiple comment links, then either the consumer can cope with
them and process both the links and counts, or the consumer can't cope
with them and can only process the combined count - but the count
alone without any links to reach the comments isn't very useful, so
why bother with it - consumers that can cope with multiple comments
links will be able to manage addition of the counts if necessary.
A variation would be to go with your proposal, but to say that ref is
optional if there is only one comments link, but would that be
fragile? People would have to remember to fix things up if they added
extra comment links - but is that going to be a common occurrence?
And implementations that add comment links will presumably be aware of
the semantics of comment links, and will therefore know about the need
to add missing refs?
Anyway, I think that any of these options is better than the current
situation.
> The value of ref is the href of a replies link appearing in the
> entry/feed/source. Where that gets nasty, of course, is when the href
> is relative and xml:base is being used to set the Base URI.
xml:base always gets nasty, but I don't see it as being a big problem
in this case.
> The updated spec would have an appendix that would explain that previous
> versions of the extension defined the attributes and that some
> implementations have been deployed that use the attributes. The spec
> will indicate that those attributes are deprecated in favor of the
> thr:count element but that feed consumers have the discretion of whether
> or not to support them.
Maintaining compatibility with an expired Internet Draft? I don't
really support that. Is it really needed:
Stage 1: Implementation X has no support for FTE
Stage 2: Implementation X supports obsolete draft of FTE
Stage 3: Implementation X supports final version of FTE
Nobody is going to consider the obsolete form to be invalid. All that
would happen if consumers don't support it, is that they won't see the
thread counts. This isn't a big deal, as before the implementations
had implemented support for FTE consumers wouldn't see the thread
counts anyway. Eventually those implementations that support the
obsolete form will be updated, and consumers will be able to process
the thread counts.
(I think the moral of this story is to, in future, not to specify
IANA-namespaced link rel until a specification has been finalised.
During development there are bound to be changes, and IANA links don't
allow versioning, or DO-NOT-DEPLOY banners in the URI (like the one we
put in Atom draft namespace). Although, to be honest, I'm amazed if
there is any real reluctance to make breaking changes to an Internet
Draft.)
> Does this work?
> - James
--
Dave
