Subject: [RFC 4287] uri of atom:category element

From: Nicolas Krebs <[email-masked]>
Date: Tue, 23 May 2006 00:08:51 +0200

Hello, 

Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287
(avaible in http://www.ietf.org/rfc/rfc4287.txt )

> 4.2.2.  The "atom:category" Element
> 
>    The "atom:category" element conveys information about a category
>    associated with an entry or feed.  This specification assigns no
>    meaning to the content (if any) of this element.
> 
>    atomCategory =
>       element atom:category {
>          atomCommonAttributes,
>          attribute term { text },
>          attribute scheme { atomUri }?,
>          attribute label { text }?,
>          undefinedContent
>       }
> 

The section 4.2.2 does not indicate how to indicate the uri/iri
of the atom:category, or an/one uri/iri where i can find info about the 
atom:category or more detailled than le label attribut, possibly html content 
with html link to other entry with/of this category, by example
"http://www.tbray.org/ongoing/What/Technology/Web/" . 

Some feed that i have read use the two attributes atom:scheme and 
atom:term in the way that, if you catenate the two, you obtain the uri/iri 
of the category (by example
"<category scheme='http://www.tbray.org/ongoing/What/' term='Technology/Web' />"
in http://www.tbray.org/ongoing/ongoing.atom . 

But the spec (rfc 4287 section 4.2.2) does not give an uri or href attribute 
wich explicitly contain the uri of the category, neither it (the spec)
say that in concatenate the two attributes scheme and term you 
can go to the uri and that feed generator/editor must ensure that the string
scheme + term is a valid uri and is the rui of the uri of the category. 

Could you explain if there is a standardized way to fin the uri of the category, 
an give piece of information about mandatory feature of sheme and term ? 
Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? 
If it is a forbiden method, will you add an atom:href or atom:uri attribute 
to the atom:category element ?

---

From: James M Snell <[email-masked]>
Date: Mon, 22 May 2006 15:26:43 -0700

Nicolas Krebs wrote:
>[snip]

There is no standardized way of referencing a URI for a category.

> Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? 

This depends on the "scheme".

The "scheme" attribute basically specifies how to interpret the term.
In the case of Tim Bray's Atom feed, Tim has defined his own scheme,
which has the unwritten rule that scheme+term = dereferenceable category
URI.  Other schemes may use a similar approach, but not all.

For example, it would be possible for someone to create a new scheme
that dictates that the term MUST be a dereferenceable URI.

  <category scheme="http://example.org/fictional/scheme"
            term="http://example.org/categories/foo"
            label="Foo" />

Some schemes may not have any form of dereferenceable API associated
(e.g. Google Data's scheme used to identify the entry type)

> to the atom:category element ? 

I brought up the possibility of an @href attribute on category a while
back and didn't get a very positive response.

- James

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 23 May 2006 00:54:39 +0200

> Could you explain if there is a standardized way to fin the uri of the category,

There isn't.

> an give piece of information about mandatory feature of sheme and term ?

There isn't either.

> Is concatenation(shme, term) a wrong/good/allowed/mandatory method ?

wrong (because not aknowledged by the spec), allowed (because not
explicitly forbidden).

> to the atom:category element ?

I'm not aware of any plan to do so. However, you might want to make up
an extension. In this case, try to avoid using foreign attributes on
the atom:category element or you'll run into the same problems James
in fighting wrt his Fead Thread Extension [1]. The problem is that, as
atom:category isn't listed in section 6.4 as containing Metadata
Elements, there's no explicit request for processors to surface any
extension to atom:category in their model representation, so they
might just be discarded.
IMO, the Simplest Thing That Could Possibily Work is to define a new
link relation, say "category", and use atom:link elements to link to
"category-related" resources. The drawback is that those atom:link
elements won't be associated in any way to the atom:category elements,
so aggregators/readers won't be able, for example, to list categories
with links on the one where an "href" is provided, all they could do
then is to list categories extracted from the atom:category elements
and list "category links" extracted from the atom:link elements with
rel="category", as two completely distinct sets.
So finally, maybe a attribute or child-element -based extension might
be better...

On the rationale side, I suspect you want to link to an HTML page
listing entries associated with the given category?
First, I think this is a too specific case for a "generic" @href.
I also don't see the need for it: those "category HTML pages" would
generally be available from the HTML representation fo the entry
(which I suspect would also exist), so they're only two clicks away.
What _could_ be useful eventually would be a link to a *feed*
containing entries associated with the given category, and in that
case I think an atom:link with a new "category" relation would be
enough. But even then I suspect "category feeds" to be not so common
or not so commonly used (I'm personnaly not subscribed to any
"category feed" and I don't even think sites I'm subscribed to provide
"category feeds"; I'd like XML.com to provide an "articles only" feed
instead of their "articles and blogs" feed, but that's not a matter of
categories –"columns" are a category for articles, and blog posts have
their own categories–).

In conclusion: YAGNI.

[1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt

-- 
Thomas Broyer