Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection

From: Beecher Greenman <[email-masked]>
Date: Wed, 14 Jul 2004 07:59:52 -0400

>>> >    <entry>
>>> >      <title>First Site</title>
>>> >      <link rel="alternate" type="text/html"
>>> > href="http://manyblogs.org/bob/FirstSite"/>
>>> >      <!-- Feed and Post URLs -->
>>> >      <link type="application/atom+xml" rel="service.post"
>>> > href="http://manyblogs.org/bob/FirstSite/post"/>
>>> >      <link type="application/atom+xml" rel="service.feed"
>>> > href="http://manyblogs.org/bob/FirstSite/feed"/>
>>> >      <!-- issued: Time when service was first published. -->
>>> >      <issued>2004-06-24T19:14:06Z</issued>
>>> >      <!-- modified: Time when blog was last updated -->
>>> >      <modified>2004-06-24T19:14:06Z</modified>
>>> >      <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
>>> >    </entry>
>
>>
>> If this resource description in the list of resource were a <site>
>> resource instead of an <entry> resource, the client would know better
>> what to do with it.

That data is redundant. A client which found this via autodiscovery
knows what types of entries to expect from the @rel attribute of the
autodiscovery link. If it doesn't use this link then it's violating most
common definitions of introspection (which need to be in the context of
the resource being introspected), and so we get an ordinary list of
links, which is really all we can hope to guess about the client's
intentions anyway.

>> Does a client discover that this "entry" is
>> really a "site" by merely the presence of, say, the "service.post" and
>> "service.feed" link?  Main-level entries have the same links (they may
>> have a PostURI and FeedURI for the entry and its comments).

No; it gets this from the fact that it is identified as
"service.introspection" (or some other suitable value of @rel) from the
service it pulled this feed from.

Although a client could theoretically pull this link without using
autodiscovery -perhaps by caching the URL from a previous date- this
violates most definitions of introspection, which normally require the
call to be in context of an object. In a case like this, the feed is
little more than a list of links.

>>> > It's worth noting that Ken MacLeod and Steve Jenson have recently
>>> > proposed that <title> and <id> elements be added to the current
>>> > PaceIntrospection proposal's <site> tag. Both of these seem to have
>>> > been inspired by the similar tags in the feed format, and since what
>>> > I'm proposing uses that format, it already includes both of those
>>> > tags.
>
>>
>> It's worth noting that thousands of resource types can have titles and
>> identifiers, but not all resource types are entries.

>> If we want to make <feed>s into generic lists and <entry>s into
>> generic metadata containers, then fine, lets get consensus on *that*
>> so that we can start specifying a new technique, rather than their
>> element type name, for discovering the resource type that really is
>> being dealt with.

We don't need to "make" <feed>s into generic lists and <entry>s into
generic metadata containers, because they are *already* defined as such.
I am doing nothing other than applying the current definition in a way
not commonly thought about, because people are still thinking of
"entries" as synonymous with blog articles (a definition discarded in
the CommentsAreEntries discussion). If you want to change it in order to
limit its applications, then that's your prerogative, but you'll be
doing just that: changing the definition.

>>     <entry>
>>       <resource-type>site</resource-type>
>>       <title>First Site</title>
>>       <link rel="alternate" type="text/html"
>>          href="http://manyblogs.org/bob/FirstSite"/>
>>       ...
>>     </entry>
>>
>> It's @rel, all over again.

I suppose it is.

- Beecher Greenman

---

From: Ken MacLeod <[email-masked]>
Date: 14 Jul 2004 09:03:48 -0500

Beecher Greenman <[email-masked]> writes:

> [Ken MacLeod wrote:]
> > If this resource description in the list of resource were a
> > <site> resource instead of an <entry> resource, the client would
> > know better what to do with it.
> 
> autodiscovery link. If it doesn't use this link then it's violating
> most common definitions of introspection (which need to be in the
> context of the resource being introspected), and so we get an
> ordinary list of links, which is really all we can hope to guess
> about the client's intentions anyway.

OK, this seems to be a very clear statement.  What this is saying is
that one should determine the content type of a resource at a
particular URI location:

 * not by its Internet Media Type (application/atom+xml),
 * not by its XML namespace (http://purl.org/atom/ns#),
 * not by its element type (namespace+localname), and
 * not by any other local means indicated within the content

but rather, solely by the external link property used to reference the
resource (<link rel="service.feed">).

That doesn't work past the first time the link is copied to some other
location, for *any* other purpose (linking, documentation, storage).
Once the link reference "leaves its home", knowledge of what the
resource "is" is lost.

  -- Ken

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 14 Jul 2004 10:38:48 -0400

> Once the link reference "leaves its home", knowledge of what the

More to the point, it violates every best practice detailed in
<http://www.w3.org/2001/tag/doc/mime-respect.html>.  Participants in
this thread who disagree with Ken would do well to read (or re-read)
that document, in particular section 5
<http://www.w3.org/2001/tag/doc/mime-respect.html#specs>, which
explicitly mentions the priority of the HTML link element as compared
to other (possibly conflicting) server-generated metadata.

-- 
Cheers,
-Mark

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 14 Jul 2004 10:49:17 -0400

> Once the link reference "leaves its home", knowledge of what the

+1 

The indication of the type of content needs to be provided
by either the media type or the  root element name (
localname + namespace), and introspection is a 
different kind of content than a feed.

   -joe

---

From: [email-masked] (John Panzer)
Date: Thu, 15 Jul 2004 08:50:51 -0700

>different kind of content than a feed.
I am not sure, but I _think_ that Bob Wyman's synthetic feed extension 
addresses the ambiguity issue between entry-data and feed-or-site-data.  
See thread starting at See 
http://www.imc.org/atom-syntax/mail-archive/msg06352.html, "Using a 
synthetic feed to find out about other feeds".

<?xml version='1.0'encoding="utf-8"?>
<feed version='0.3' xmlns='http://purl.org/atom/ns#' xmlns:ps='http://www.pubsub.com/xmlns'>
   <link rel='alternate' type='text/html' href='http://example.com/bugsbunny'/>
   <modified>2004-07-07T18:36:11-04:00</modified>
   <author>
      <name>Bugs Bunny</name>
   </author>
<title><![CDATA[Bugs Bunny's Blogs]]></title>

<entry>
  <ps:source-feed>
    <title><![CDATA[Title of my First Blog]]></title>
    <link rel='alternate' type='text/html' href='http://example.com/bugsbunny/MyFirstBlog'/>
    <link rel='???' type='application/atom+xml' href='http://example.com/bugsbunny/MyFirstBlog.atom'/>
    <link rel="service.post" type="application/atom+xml" href="" class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">"http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi"/>
  </ps:source-feed>
  <issued>2004-07-07T19:34:10-04:00</issued>
  <content>...</content>
</entry>

It's unambiguous which data is associated with the feed.  Synthetic 
feeds are also something that aggregators will have to deal with in any 
case.  Can these same mechanisms be used for introspection?  (My 
position is that introspection-like-things will happen using synthetic 
feeds in any case, because they're generally useful.)

I'd be interested to hear reactions to this concept.  Is it helpful, or 
just more noise?

-John

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 16:25:17 -0500

[email-masked] (John Panzer) writes:

>     <link rel="service.post" type="application/atom+xml"
>       href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">
>   </ps:source-feed>
> feeds are also something that aggregators will have to deal with in
> any case.  Can these same mechanisms be used for introspection?  (My
> position is that introspection-like-things will happen using
> synthetic feeds in any case, because they're generally useful.)

The above clearly distinguishes the site information in the entry
using the element type name ps:source-feed, the aggregator should use
that to say "original from feed Title of my First Blog" or the like,
but the feed does not indicate in any way that "this feed is not just
a bunch of entries from different blogs, it's a feed of blogs that you
should use to report new blogs to the user".  It still needs another
bit of information for that, maybe,

   <resource-type>feedlist</resource-type>

  -- Ken

---

From: Beecher Greenman <[email-masked]>
Date: Mon, 19 Jul 2004 07:47:59 -0400

>  * not by its XML namespace (http://purl.org/atom/ns#),

These last two cannot be used to determine the content type (as opposed 
to MIME type) anyway, because it has already been decided that there is 
only one of each of these for all Atom documents.

>  * not by its element type (namespace+localname), and

Namespace does not matter, as we've noted, because there is only one 
namespace for all Atom documents, unless you are willing to propose another.

>  * not by any other local means indicated within the content

Last I checked, Atom was an API, not a file format. As such, a feed 
loses most if not all of its meaning when it is references other than by 
its URI, as this is the mechanism used to call it. That is a consequence 
of the REST design we are using: without a URI or some other call point 
the document loses its meaning.

> Once the link reference "leaves its home", knowledge of what the

I reiterate: this is a consequence of REST. To add this information in 
would violate that design principle, perhaps in a minor way but not an 
insignificant one. A client which needs to use this information in some 
sort of cached manner can cache the URL used to call it. Indeed, it 
already needs to do this, so that it can refresh the document as 
necessary. Given that it needs to store the URL, context need not be lost.

If there is truly a need to define what a feed is outside the context of 
its call, then that need exists whether or not we use feed-based 
introspection, because we have already "dual-purposed" <atom:feed> to 
describe both sites and contents within sites (see ContentsAreEntries). 
If such an element is already needed (<atom:resource> perhaps?) for 
"site" and "article" feeds, then it is trivial to add "introspection" to 
the list of allowable types.

- Beecher Greenman

---

From: Beecher Greenman <[email-masked]>
Date: Mon, 19 Jul 2004 08:12:56 -0400

> to other (possibly conflicting) server-generated metadata.
I would agree with you, but there is a problem with using MIME to 
determine the feed's content type: we only have one MIME type for all 
Atom documents at this point. "application/atom+xml" is useful for 
determining that a document is Atom, but by itself it cannot tell us 
anything more about it. If we want to instead use one MIME type for each 
kind of Atom call, perhaps "application/atom+xml:introspection", 
"application/atom+xml:syndication", and "application/atom+xml:edit" 
among others, then MIME types would come into play. At the present, 
however, these MIME types do not exist.

This said, since we need the URL to provide the context for what the 
file means, there are several ways of providing it if we don't want to 
rely on clients to cache it. The way which changes the spec the least 
would be to add to <atom:link>, perhaps with a new @rel value of 
"call-point" or even by adding the little-used @rev from HTML in, with a 
value of "introspection". Either suggestion is likely to get me 
crucified here, but if we're going to use REST then we may as well be 
hardcore about it.

On the other hand, perhaps there is a need for, as Ken suggested, an 
<atom:resource-type> attribute. If this would be needed for 
introspection, then we already need it for feeds anyway, as a matter of 
distinguishing when a feed lists articles and when it lists comments, so 
it cannot be considered a real barrier to using feeds for introspection.

- Beecher Greenman