Brian Smith wrote:
I tried doing something similar:
<atom:category term="dog" label="Dog" >
<atom:id>http://example.org/categories/dog</atom:id>
</atom:category>
I like that. Part of me thinks atom:category could evolve into something
that carries a lot of metadata; be a specialised entry if you like.
On the other hand, reusing the existing markup like this
creates a lot of problems when people give different semantics
to the same construct, as shown above. That is why I stopped
trying to reuse any existing markup for new purposes.
Sure, but that's a generalization. I'd ask, where is the specific
problem here? Your first case, embedded atom:id, seems consistent to
me. And so does an embedded atom:link in my category case. And as I said
before, in the category case, it's preferrable to drilling links into
@term or overloading @scheme to be a link. It's unfortunate that Atom
categories aren't resources by design.
That said, I tend to think about semantics in the formal sense of the
word; Atom doesn't have any.
By the way, I think it would often make more sense to say
"please categorize the things with those ids using this
category" by making each category its own AtomPub collection,
and then POSTing links to the collection:
I didn't say it, but that example is taken from a document where
categories have feeds (and are accessible as collections). Since what
I'm doing is creating a relationship between two existing things, it
felt more natural to use a distinct service for that.
By the way, why did you decide to link to entries
using their atom:id, instead of by their URI?
Because entries (and feeds) are identified using atom:id. Strictly
speaking, I'm not linking here, I'm categorising.
The major problem with linking by atom:id is
that atom:id is not a unique identifier (even though it
> is *supposed* to be), but a resolvable HTTP URL can be
> guarenteed unique as long as you control the servers that
handle that URL.
Maybe; but I prefer to follow the spec text in this case rather than
make assumptions about what might be the case.
Bill
