Antone Roundy wrote:
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?
Sorry, I don't buy that as an argument against using atom:link here. If
you want crisp denotations, use RDF or OWL or KIF, not the link rel
registry.
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.
I don't agree, mainly because I doubt you could define "related" so that
it excludes the option I gave.
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.
No, because I see the spirit of the RFC as allowing what it does not
explicitly disallow. Hence the RNC is non-normative.
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.
I could agree with this...
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.
...but this doesn't follow. "New Atom markup" meaning the same thing as
"the current markup in an undefined place" isn't a reasonable
interpretation.
I would say "huge gaping hole in the spec" were it not for my opinion
that the WG worked on a default allow basis and the intent was never to
restrict this kind of usage.
Bill
