Subject: PaceContentSrc and other content indirection concepts

From: Antone Roundy <[email-masked]>
Date: Mon, 30 Aug 2004 11:11:21 -0600

Although I recognize the value of being able to offload content from a 
feed, and after turning this issue over in my mind for a while, I'd 
have to say -1 to this proposal for two reasons:

1) It allows indirection of all Content Constructs.  I think it would 
be better to limit indirection to <content>.  There might be a case for 
allowing it for <summary> too, but I think I'd prefer not to allow that.

2) I think I'd rather do content indirection in a different way.  The 
rest of this email will introduce that way.  Let me know (off list, 
perhaps) if you'd support a proposal along these lines.  If I get 3 
supporters, I'll write a proposal.

Clearly, there are cases where data that is part of an entry is not 
going to be delivered within the Atom feed.  The most obvious example 
is images referenced from (X)HTML content.  Other possible examples 
that have been proposed[1] include favicons and images referenced by 
other means like <image> and <enclosure> in RSS.  If any of the 
proposals for limiting content to text or (x)html are accepted, then 
all other content types will either end up in extensions or fall into 
this category.

Rather than allowing indirection of the <content> element, I'd prefer 
to create what I'll call an Embed Construct.  Embed Constructs would be 
used to reference external content to be embedded within the 
presentation of an entry.  They might look like one (or more) of the 
following:

<embed rel="icon" url="..." type="image/gif" />
<icon url="..." type="image/gif" />
<image url="..." title="Family Photo, June 2004" />
<embed url="..." type="quicktime/mov" content-length="1000000" 
title="Content: The Motion Picture" />
<movie url="..." content-length="1000000" title="Content: The Motion 
Picture" />
<embed rel="content" type="text/html" url="..." /> <!-- instead of 
<content src="..." /> -->
<embed rel="content" type="text/html" url="..." xml:lang="..." />
<embed rel="content" type="mathml" url="..." /> <!-- not the correct 
MIME type, but I didn't feel like looking it up :-) -->

Points:

* Some name other than <embed> might be good to differentiate from 
HTML's <embed> tag.  But not having thought of a better name, I'd be 
fine with <embed>.
* Possible attributes: rel, url, type, content-length (or size), title.
* All but @url would be optional.
* @type and @content-length would be only advisory.
* @rel could be optional, with no default if omitted.  Useful values 
for when one DOES want to specify the relationship would include icon 
(or favicon...maybe) and content ("this IS the content, or an 
alternative version (eg. in different language) of the content" to 
differentiate it from things intended to be rendered alongside 
<content>, if present).  Any others?
* <embed rel="content" /> might appear awfully similar to <link 
rel="alternate" ... />.  The difference is twofold: subjective intent 
of the publisher (<link> points to another way to look at the content, 
<embed> to the content the publisher wants the feed reader to render), 
and <embed> should point to a resource containing ONLY the atom:entry 
content, while <link> might point to a web page containing the 
atom:entry content as well as site navigation, advertising, etc.
* I'd prefer @rel to a variety of elements.
* I think I'd be fine with a closed list of @rel values.  If people 
come up with a lot of @rel values for concepts that wouldn't be well 
served by omitting @rel, I might change my mind.

Antone

[1] http://www.intertwingly.net/wiki/pie/LinkTagMeaning

---

From: Antone Roundy <[email-masked]>
Date: Mon, 30 Aug 2004 11:22:10 -0600

On Monday, August 30, 2004, at 11:11  AM, Antone Roundy wrote:
>  Embed Constructs would be used to reference external content to be 
> embedded within the presentation of an entry.  They might look like 
> one (or more) of the following:

Oops, missed an important alternative:

<embed url="..." type="image/jpeg" >
	<title>Family Photo, June 2004</title>
	<height>50</height>
	<width>100</width>
</embed>

...which raises the question of what child elements might be allowed.  
This is starting to feel like something that might belong in an 
extension, except that for some uses, it seems fundamental enough to 
not want to push it out of the core.  Hmm.  Perhaps put the basic 
concept in the core, and allow extensions to add child elements as 
desirable for particular data types?

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 30 Aug 2004 14:48:53 -0400

Antone Roundy proposed <embed> tags to hold external content.

Antone's suggestion appears to be similar to what is provided by
"attachments" in a number of other XML formats. Also, note that NITF,
defined by the same folk[0] that define NewsML provides a "media"[1] tag to
reference non-text or external components. NITF is used by many in the
newspaper, press release and content syndication businesses. 

For instance:
<body.content>
	<p>Today, <org value="MSFT" idsrc="NASD">Microsoft</org>
	announced the release of....</p> <p>That company is <em>so</em> big
	that they....</p>
	<media media-type="image">
		<media-reference
			mime-type="image/jpeg"
			source="http://example.com/gates.jpg"
			alternate-text="BillGates at the podium.">
		</media-reference>
		<media-caption>
			Gates makes speech.
		</media-caption>
	</media>
</body.content>

Media types include: text | audio | image | video | data | application |
other
Media-Reference[2] has a pretty long list of candidate properties...
A "media-object"[3] element is provided to support in-line content in place
of the media-reference element.

[0] http://www.iptc.org/
[1]
http://www.nitf.org/IPTC/NITF/3.2/documentation/nitf-documentation.html#medi
a
[2]
http://www.nitf.org/IPTC/NITF/3.2/documentation/nitf-documentation.html#medi
a-reference
[3]
http://www.nitf.org/IPTC/NITF/3.2/documentation/nitf-documentation.html#medi
a-object

---

From: "John Panzer" <[email-masked]>
Date: Mon, 30 Aug 2004 17:28:11 -0700

> allowing it for <summary> too, but I think I'd prefer not to allow that.

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

 > ...

I'd also ask that the editing (API) case be considered in any indirect 
content proposals (see the cat picture posting use case).  Sometimes 
this requires flipping back and forth conceptually.  How complicated 
will/should it be for editing tools to deal with content indirection?

 > <content>, if present).  Any others?

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?

 > atom:entry content as well as site navigation, advertising, etc.

(Also, conceptually this would presumably point just at what would 
otherwise be in <content>, not necessarily including things that map to 
<summary>, <title>, etc.)

I think this proposal is a generalization of <content @src>, and would 
provide a superset of the benefits.  So, in principle, I wouldn't object 
to seeing a worked out proposal and would support it if there were 
consensus for it.

-John

---

From: Robert Sayre <[email-masked]>
Date: Mon, 30 Aug 2004 22:47:07 -0400

Antone Roundy wrote:

> 
> Rather than allowing indirection of the <content> element, I'd prefer to 
> create what I'll call an Embed Construct.  Embed Constructs would be 
> presentation of an entry.  

-1. Embedded in what? Atom is free of presentation assertions.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 31 Aug 2004 19:16:49 -0600

On Monday, August 30, 2004, at 08:47  PM, Robert Sayre wrote:
>> to create what I'll call an Embed Construct.  Embed Constructs would 
>> be used to reference external content to be embedded within the 

It's always a little tricky finding words that say what you mean and 
don't saying anything you don't mean (as well as getting a clear enough 
picture of what you mean to have a chance at finding the right words).  
"Embed" was an imperfect word.

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.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 21:28:04 -0400

> 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?

Robert Sayre

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