[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal to register rel="about"




Erling Wegger Linde wrote:
On Fri, Sep 12, 2008 at 4:45 AM, Antone Roundy <electriceel@xxxxxxxxx> wrote:
Herbert van de Sompel wrote:
The Atom use cases we refer to use Entries as containers to provide
"metadata" about some web resource other than the Entry itself. For example,
the GData Entry <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io > is
about the YouTube video by the Cribs
<http://www.youtube.com/watch?v=S_bcAOlK0io>
My impression upon looking at the entry is that you could do this instead
(and add an atom:summary element with textual content):

<content src="http://www.youtube.com/watch?v=S_bcAOlK0io"; />

I have another use case which I personally think justifies registering
the rel="about" for Atom Entries, please correct me if I'm wrong about
this.

What if you use Atom entries as wrappers for other resources?

It seems to me that that's exactly what <content src="..." /> is for.

You could not embed the
represenation found at http://issuetracker/project1/issue1 in the
entry using <content src="http://issuetracker/project1/issue1";> as
this probably would be hard for a non-human client to parse.

Well, you could, but as you say, some clients wouldn't handle it...very well. That's why, when there's no textual content in atom:content, atom:summary is required.

you could of course create a new
resource/representation e.g http://issuetrackerwrapper/projec1/issue1
and link this into your Atom entry, but I think that would be a waste
of energy and resources, compared to just use <content
type="application/rdf+xml">RDF content here..</content>.

So either the content can be presented inline within the feed somehow, or it can be linked to somehow. I don't see the advantage of link/@rel=about over content/@src=... as the linking method.

The idea of a link relation changing the meaning of a core Atom element
doesn't sound right to me.

After sending my message yesterday, I thought I probably should have amplified this objection more. Allowing a link/@rel value to alter the meaning of core Atom elements would be dangerous, because implementations that don't understand the new @rel value (which they're not required to do, and we rejected the idea of creating any sort of "mustUnderstand" mechanism) would misinterpret the core Atom elements.

If you don't use content/@src to make the external resource the "content" of an Atom entry, but you want the entry to contain metadata about the external resource, then I think you need to put that metadata into extension elements designed for that purpose.

Antone