Bill de hOra wrote:
Brian Smith wrote:
Bill de hOra wrote:
2: the scheme is arguably not adequate to express something like a
category feed; it does tell you the vocabulary/type of the category
item, but not that there's an alternate/related resource.
I don't understand what you intend "alternate" to mean here. How can a
feed be an alternate representation of a category? Is the feed
supposed to list entries that have been marked with that category?
Alternative categories that could be used instead? Something else?
"related" might be better?
And here we see the problem using using atom:link this way -- there's no
standard way to do it, and no standard interpretation of it. Would a
"related" feed be the feed of entries in that category, or some
arbitrary feed on the same topic?
Perhaps it would be best to mint another link relation for the
category's feed. Or to use an extension attribute to point to it.
But there is the issue you of whether the RFC allows it. As I read it,
Atom markup in an Atom document may appear only in the places where the
RFC says it can. I see two possible ways around that (both of which I
disagree with):
1) Since it's not EXPLICITLY stated that way, maybe it's not the case.
2) Atom markup in places not specified in the RFC could be treated as
"foreign markup". Section 6.4 says:
Atom allows foreign markup anywhere in an Atom document, except where
it is explicitly forbidden.
And section 6.2 says:
unrecognized markup from the Atom vocabulary will be
considered "foreign markup".
While I suppose one could argue that this means markup from this RFC
appearing in places where this RFC doesn't allow it, I read it in
context to be referring to markup added to the Atom vocabulary by future
versions of the spec.
Section 6.2 says:
Future versions of this specification could add
new elements and attributes to the Atom markup vocabulary.
...which isn't exactly the same as saying that future versions could
specify that existing elements and attributes can appear in places where
they previously couldn't, but it seems to me that it's basically the
same thing -- it's the prerogative of the WG to create future versions
of the spec to make such changes.
Antone
