Subject: Re: PaceContentSrc and other content indirection concepts

From: Antone Roundy <[email-masked]>
Date: Tue, 31 Aug 2004 22:12:25 -0600

On Tuesday, August 31, 2004, at 07:28  PM, Robert Sayre wrote:
> Antone Roundy wrote:
>> The point is that rather than building indirection into the <content> 
>> element, I'd prefer to create a more general mechanism for 
>> referencing external data that is part of the entry (as opposed to 
>> <link>, which is used to refer to external data which has some 
>> relationship to the entry).  We can call it <import>, <external>, 
>> <media>, or whatever.
>
> Ok, fair point. But we have been here before[0]. My view is that you 
> can use HTML to do this. Embedding is only meaningful for documents, 
> not metadata. Do you understand my problem with this?

I think I have at least fuzzy idea of it.  The point that HTML can be 
used for embedding is partially persuasive, but especially in light of 
the restrictions we appear to be moving toward on what can appear 
inline in <content>, I think we need to be sure we have a viable 
solution for referencing kinds of data that won't easily fit in there, 
and for accessibility.

I'll have to ask for the opinions of people more familiar with things 
like MathML regarding whether there are good ways to embed them in HTML 
or whether it would make more sense to reference them some other way.  
Among other things, an Atom-specific method might make it easier for 
clients to control whether or not external content is downloaded 
automatically or whether it's only downloaded in response to 
interaction with the user, which could be useful especially for large 
resources.

We don't yet have a way to reference things like icons and images, for 
which elements exist in RSS.  There's a certain amount of sense to the 
idea that images should be referenced from within <content> so that the 
publisher can control the presentation, but the precedent does exist 
for doing otherwise.

I don't think I'd noticed till it was mentioned earlier today that the 
spec had changed to allow multiple <content> elements (that wasn't 
allowed on 0.3, was it?).  Looking at the spec right now, it doesn't 
provide any guidance regarding what it means to have multiple <content> 
elements.  Are they alternatives for each other, or does each carry 
separate content?  And are we going to do away with multipart content 
and/or multiple content elements?  Depending on what happens on that 
front, we may need an accessibility solution.  Content indirection for 
alternative representations seems like a good direction to me (not 
<link rel="alternate" ... />, but a pointer to a location from which to 
retrieve exactly what would have been put into <content> had the 
publisher preferred the format pointed to rather than the one they 
actually put in the feed).

It may be that the best solution is to allow multiple <content> 
elements, each of which may carry it's content inline or refer to 
external content, and each of which (I would think) would be an 
alternative representation of the same content; and to use some other 
element to point to icons and images (not <link>, I would hope).  Or it 
may be better to create a new element to point to external data which 
could handle all of these cases.  Seeing that, at present at least, 
multiple <content> elements are allowed, has moved me back to where I 
think I could go either way (I'm not fond of multipart <content>).

> [0] http://www.intertwingly.net/wiki/pie/PaceObjectModule

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 03 Sep 2004 22:24:40 +0200

On Mon, 30 Aug 2004 17:28:11 -0700, John Panzer <[email-masked]> wrote:

> I agree.  Does anyone object to changing the Pace to specifically talk
> about atom:content only instead of Content Constructs?

I agree as well, so no; I don't object.

> How complicated will/should it be for editing tools to deal with content
> indirection?

It isn't very difficult. It's as difficult as it is to upload e.g. an  
image, store somewhere, and insert a new row in a database with the path  
to the image. That can be done with all resources.

> Questions which pop up: If you have <embed rel="content">, can you have
> <content> as well, and if so why?  What if you have multiple <embed
> rel="content"> elements?

Sorry, but I haven't understood the real point in the <embed> element.  
What is it?

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»