Subject: PaceContentSrc (and NewsML similar mechanism)

From: "Bob Wyman" <[email-masked]>
Date: Sat, 28 Aug 2004 16:51:56 -0400

It may be useful to note that NewsML[1] supports indirect contents
in a manner similar to that discussed in PaceContentSrc.
    NewsML supports the "Href" attribute on "ContentItem" to allow
indirect content inclusion: (I think "Href" in NewsML does what "src" is
proposed to do in PaceContentSrc.)
...
<ContentItem Href="http://example.com/example.html">
  <MediaType FormalName="Text"/>
  <Format FormalName="XHTML"/>
</ContentItem>

The same content would be in-line if the Href attribute is omitted:
...
<ContentItem>
  <MediaType FormalName="Text"/>
  <Format FormalName="XHTML"/>
  <DataContent>
   <xhtml><p>This is an example.</p></xhtml>
  </DataContent>
</ContentItem>

		bob wyman

[1] http://www.newsml.org/pages/index.php

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 00:33:32 +0200

> in a manner similar to that discussed in PaceContentSrc.

Yes, that's very useful. I support this pace fully.

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

---

From: Eric Scheid <[email-masked]>
Date: Sun, 29 Aug 2004 13:56:58 +1000

+1 to optional content indirection.

Note, since this suggests that implementations would automatically retrieve
resources from heretofore unseen URIs that there is a security issue, and
should be noted in the spec.

Examples:

    <entry>
        <content src="javascript:evil(1);" />
    </entry>

    <entry>
        <content src="file:format%20c" />
    </entry>

(both not actual exploits, I would hope)

e.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 29 Aug 2004 07:48:34 -0400

>         <content src="javascript:evil(1);" />

Note: javascript is not an IANA registered scheme.

http://www.iana.org/assignments/uri-schemes

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 15:47:39 -0400

Eric Scheid wrote:
> +1 to optional content indirection. Note, since this suggests that 
> implementations would automatically retrieve resources from
> heretofore unseen URIs that there is a security issue, and
	It should also be noted that there is a minor risk of DDOS attack
here as well. If cients automatically retrieve indirect content, then one
might publish a large number of indirect links in a popular feed in order to
generate (number_of_links * number_of_readers) accesses to a remote, and
presumably fragile, site. This is, of course, no different than many other
similar opportunities on the web and should not, I think, be of distinct
concern -- nonetheless, it should be mentioned.

		bob wyman

---

From: Graham <[email-masked]>
Date: Sun, 29 Aug 2004 16:55:06 -0700

I fundamentally disagree without an explanation of what might be found 
at the end of the URI, and clear use cases for such.

Graham

---

From: [email-masked] (John Panzer)
Date: Sun, 29 Aug 2004 19:50:55 -0700

> at the end of the URI, and clear use cases for such.

The common type of resource at the end of the URI would probably be a 
picture, sound or video.

Some use cases:

Syndication:  We have an entry which consists of a single cat picture, 
with a title, possibly a summary, some metadata, etc.  PaceContentSrc 
offers a way to express this directly as an Atom entry (as directly as 
one can without embedding binary data in an XML data stream). 

Editing:  Someone wants to create or edit an entry consisting of a 
single cat picture (this is the degenerate case of the general 
multi-cat-picture use case ; see 
http://journals.aol.com/panzerjohn/abstractioneer/entries/452.)  We have 
to upload the bits and relate them to an Atom entry; this offers a 
simple way to do so.  See also PaceSimpleResourcePosting.

-John

---

From: Graham <[email-masked]>
Date: Mon, 30 Aug 2004 10:33:37 -0700

> The common type of resource at the end of the URI would probably be a 

As I've said before, the better and simpler way to do this is by 
embedding the link in HTML. Think about the implementors for once.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 30 Aug 2004 13:49:15 -0400

> embedding the link in HTML. Think about the implementors for once.

I know we've done several laps on this one, and we disagree. You've 
rightly pointed out that people are having a hard time coming up with 
reasons not to make link optional, so I'll ask the same of you here.

The conversations we've had before have gotten pretty heated and 
unproductive, so I'm afraid I still don't understand where you're coming 
from.

Could you give us an example of a nightmare for aggregator implementors 
that this feature enables? I see the alternative as being a bunch of 
extension content constructs.

Speaking as a user, I would be much happier if I never had to see 
someone's crufty "audioblog" fake UI chrome gifs again. Should 
aggregators show object tags by default? I would be pissssed if my 
aggregator started firing up the RealPlayer and such. Why is it better 
and simpler to require embedding?

Robert Sayre

---

From: Graham <[email-masked]>
Date: Mon, 30 Aug 2004 11:04:25 -0700

The problem is having to implement special code for each media type. 
The vast majority of aggregators shuffle off all difficult parts to a 
browser widget - so either I have to come up with appropriate HTML 
code, or the publishers do, and they'll almost always be able to do a 
better job.

On the other hand, I do understand the elegance of leaving the link 
naked for clients that need it. There's a suggestion somewhere to limit 
the tag only to the <content> tag, not the other content constructs. If 
we go a step further and have it in a separate element, we could have 
both, eg:

<content type="xhtml">
	<object src="whatever.mov" width="320" height="240" />
</content>

<contentlink src="whatever.mov" />

(NB I don't actually know the HTML for embedding a QuickTime movie, so 
that code may be incorrect, which is pretty much my point)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 30 Aug 2004 15:27:54 -0400

Graham wrote:

> The problem is having to implement special code for each media type. The 
> vast majority of aggregators shuffle off all difficult parts to a 
> browser widget - so either I have to come up with appropriate HTML code, 
> or the publishers do, and they'll almost always be able to do a better job.

I don't understand why you think you need to write HTML.
Click this [QT]:
http://movies.apple.com/movies/fox_searchlight/napoleon_dynamite/napoleon_dynamite-sref.mov

IE6/win, Firefox, and Safari seem to take care of the layout without any 
surrounding markup.

The object/embed tags have always been used for positioning multimedia 
content in extravagant HTML layouts. Why would you need it for an 
aggregator?

> the tag only to the <content> tag, not the other content constructs. 

I would definitely support this. It hadn't sunk in that this would make 
it ok for summaries, etc.

> If 
> we go a step further and have it in a separate element...

OK, we could do that.

I'd also like to point out that we are inventing nothing here. An 
atom:entry with title, summary, and indirect content would be roughly 
equivalent to RSS2 with title, description, and enclosure. It would just 
be free of implied behavior[0], so it would make sense to put photos and 
such in content @src.

Robert Sayre

[0] 
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af

---

From: Graham Parks <[email-masked]>
Date: Mon, 30 Aug 2004 18:57:27 -0400

>I don't understand why you think you need to write HTML.

Check the screenshot:
http://www.fondantfancies.com/shrook/

I display the title, author, etc in the same widget as the body. There's no elegant way to do this and display binary content without wrapping the object in HTML.

>be free of implied behavior[0], so it would make sense to put photos and 

It's completely different. RSS defines it as in addition to the body of the entry. Atom would have it as an equally-acceptable choice for the body. That's my problem.

Graham

---

From: "John Panzer" <[email-masked]>
Date: Mon, 30 Aug 2004 16:30:56 -0700

> http://www.fondantfancies.com/shrook/

Very nice (makes me long for that cinema display even more...)

 > I display the title, author, etc in the same widget as the body.
 > There's no elegant way to do this and display binary content without
 > wrapping the object in HTML.

Yes.  I have exactly the same issue when generating a web page 
representation of such an Atom entry.  What I would do, in the case 
where "content is an image", is to generate synthetic HTML for display 
purposes:

<title>My Title</title>
<content src="..."/>

would map to:

<body>
<h1>My Title from atom:title element</h1>
<span ...>
    <img src="...">
</span>
</body>

-John

---

From: Robert Sayre <[email-masked]>
Date: Mon, 30 Aug 2004 20:02:35 -0400

I'll leave the display issue alone for the moment, let's look at some 
sample feeds.

> It's completely different. 
> RSS defines it as in addition to the body of the entry. Atom would have it as an equally-acceptable choice for the body. That's my problem.
> 

I noticed that Shrook 2.12 doesn't appear to support enclosures.

I've hijacked a few entries of Adam Curry's for some audio blog examples:

http://franklinmint.fm/enclosuresample.rss
http://franklinmint.fm/enclosuresample.atom

The RSS feed is valid. The Atom feed, nearly so. Since Shrook appears to 
  use summaries only when <content> isn't present, why would its code 
have to change in the presence of indirect content? Display the summary 
and do what you can with the content @src. Worst case, it would be no 
different than link rel="content", or <enclosure> if it was supported.

Robert Sayre

---

From: Graham Parks <[email-masked]>
Date: Mon, 30 Aug 2004 20:17:52 -0400

Okay, so let's agree that implementing the legitimate uses isn't impossible, though it is a hassle.

My real problem is how open to abuse it is, eg:

<entry>
  <link rel="alternate" type="text/html" href="http://www.example.com/blog/2004/8/29/entry/" />
  <content type="text/html" src="http://www.example.com/blog/2004/8/29/entry/" />
</entry>

There are people that will do crap like this and think it's clever, and because the feed validates expect it to be shown "correctly". How do you plan on discouraging them? We need something in the spec to point such assholes at. What have you got?

Graham

---

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

> embedding the link in HTML. Think about the implementors for once.

Some reasons for providing native Atom support for indirection, rather 
than relying on HTML, are:

o To better support editing tools -- why should editing tools have to 
both construct and parse HTML just to put and get pictures for editing? 
  It's crufty.  How does an editing tool distinguish between an entry 
that consists of a picture, and an entry that _points at_ one or more 
pictures?  How does it know whether it's OK to regenerate the wrapper HTML?

o To help make binary resources "first class citizens" within Atom, and 
let their metadata be expressed as Atom metadata (e.g., <title>).  If 
you are forced to wrap your cat pictures within HTML wrappers, does the 
title apply to the HTML or to the picture?  What about dates?  (Whatever 
they may ultimately turn out to be...)

I think that using HTML wrappers are fine for many types of 
presentation.  But, I think that it runs into problems when you start to 
consider round-trip editing and more unconventional use cases.  (Think 
about a feed that consists of all of the photos on your WiFi-enabled 
digital camera... suitably access controlled, of course.)

-John

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 15:30:17 -0700

There is prior art for this one in RSS enclosures; not widely used, but 
Dave Winer's always saying how wonderful they are when they're working. 
  I would think that if you were going to do this, it would be at least 
good practice that if you had <content src="something"> you ought to 
have some information around to enable client software and human beings 
to decide whether they are interested in fetching the linked-to object; 
for software, type= and for humans <atom:description>.

Given that, you'd probably want to allow arbitrary media-types on a 
type= attribute, which interacts with the PaceContentAsTextOrXHTML and 
PaceSimpleContentType.

I think that leaving this out won't damage Atom excessively, and 
putting it in will add complexity, but only moderately.  I would lean 
slightly to leaving it out but wouldn't block consensus either way. 
-Tim

---

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

> There are people that will do crap like this and think it's clever, and because the feed validates expect it to be shown "correctly". How do you plan on discouraging them? We need something in the…

My first instinct is that it's obvious the method for getting 
applications to inline content is to put it inline.

I admit I'm having problems coming up with spec language, since Atom 
doesn't say anything about displaying entries "correctly". If I were an 
asshole, I could complain that Shrook doesn't display summaries, even 
when they contain unique text.

Your point is a good one, but I don't think it's limited to this 
feature. It's tough to address when section 1.3 of the format spec is 
empty. Here's what it says right now:

"1.3  Conformance

    [[ talk about atom documents and atom consumers, and how requirements
    are placed on them ]]"

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 23:47:33 +0200

> type= attribute, which interacts with the PaceContentAsTextOrXHTML and  

The interaction with these two paces is good that you point out. I think  
it's important that we have a uniform way to describe things, and since we  
already have the @type attribute, it is a low syntactical cost to add an  
@src attribute to go along with it.

I understand that just serving everything inside atom:content to an HTML  
widget is what most visual desktop aggregators would do, and most web  
based aggregators would just spit it out inside some other HTML.

But not all aggregators work like this. We have machine-to-machine  
scenarios where HTML-parsing just adds overhead, and we have other use  
cases for Atom where the intent is not to display anything beautiful to  
the user at all. Or maybe the sole purpose of the aggregator is to display  
images and nothing else (think about Nokia's image frames and such -- they  
could be driven by Atom).

> I think that leaving this out won't damage Atom excessively, and putting  
> it in will add complexity, but only moderately.  I would lean slightly  
> to leaving it out but wouldn't block consensus either way. -Tim

Just so I've said it; I want it in.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 01 Sep 2004 00:13:59 +0200

> at the end of the URI, and clear use cases for such.

You know that from @type. Something should be done with the optionality of  
this attribute, though, especially when @src is used. I would say that  
when @src is present, @type MUST be too.