A. Pagaltzis wrote:
>[snip]
> I don’t know if I like it. It really, *really* departs from
> “something that’s as simple to implement as possible,” doesn’t
> it? Not only is this just as hard for consumers to implement as
> previous sketches, it’ll *also* annoy publishers, I think.
>
Yep.
> Question: what is the reason you are so staunchly opposed to
> cloning `atom:link` for the extension’s purposes?
>
I am very much against the idea of encouraging extension developers to
go off and clone core Atom elements whenever they want to provide some
additional piece of information. e.g., Say I create a thr:link. what
value would that add to end users and feed reader implementors?
OpenSearch already has their own os:link. Gdata has entryLink and
feedLink (which aren't clones of atom:link, but are still links
nonetheless). The more we clone and duplicate the function of atom:link,
the less valuable and useful atom:link becomes, and the more we put
undue burden on feed consumers.
> I’m starting to think that that is the only sane answer. If you
The only sane answer would have been to make link extensible. If I
thought it would actually be a fruitful exercise, I would suggest that
we amend rfc4287 to make it extensible, per section 4.1.1 of RFC2026:
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change ... of the specification
before it advances.
However, for now, I think I'll proceed by simply dropping the count and
when from the draft. The folks who want those things can add them back
under a different namespace. It's not worth chasing our tails over two
pieces of optional metadata. I've already prepared a draft -10 that
removes the attributes complete, I just haven't sent it off yet.
- James
