Subject: PaceIntrospection: New Examples for Feed-Based Introspection

From: Beecher Greenman <[email-masked]>
Date: Fri, 09 Jul 2004 07:53:37 -0400

I apologize for my extended absence from the list. I've been asked to 
provide some use cases for the feed-based introspection we've been 
discussing; here are two.

Use Case: Presenting a list of services to a service's owner
============================================================

A user "bob" is responsible for several services on example.org. He 
wants to see a list of every service for which he is responsible, in 
order that he may choose between them inside his client. The client 
requests this at a URL dedicated to this task, perhaps 
http://example.org/users/bob/services.atom. The server returns an Atom 
feed, similar to the following (comments have been added to the first 
entry):

Example
-------

<feed version="0.3"
   xmlns="http://purl.org/atom/ns#" xml:lang="en">
   <title>Blogs for bob</title>
   <!-- link rel="alternate": This could point to an HTML-based list
     ** of sites, or possibly a user's profile, be it public
     ** or private. -->
   <link rel="alternate" type="text/html" 
href="http://manyblogs.org/users/bob"/>
   <author>
     <name>bob</name>
   </author>
   <!-- modified: Time when the last service was created or updated -->
   <modified>2004-06-24T19:14:06Z</modified>
   <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>
   <entry>
     <title>Second Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/SecondSite"/>
     <link type="application/atom+xml" rel="service.post" 
href="http://manyblogs.org/bob/SecondSite/post"/>
     <link type="application/atom+xml" rel="service.feed" 
href="http://manyblogs.org/bob/SecondSite/feed"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/SecondSite</id>
   </entry>
   <entry>
     <title>Third Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/ThirdSite"/>
     <link type="application/atom+xml" rel="service.post" 
href="http://manyblogs.org/bob/ThirdSite/post"/>
     <link type="application/atom+xml" rel="service.feed" 
href="http://manyblogs.org/bob/ThirdSite/feed"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/ThirdSite</id>
   </entry>
</feed>

Use Case 2: Answering Silly Questions
=====================================

There has been some debate on whether an introspection file ought to 
include the site's capabilities or not, since these can be found in the 
<link> tags of the service's HTML (and usually its associated feed) as 
well. While I disagree with the idea of disallowing capabilities 
completely, I can see utility in making capabilities optional. A server 
might, for example, only send capabilities to people authorized to use 
them. In any case, here is a use case which covers one possible scenario.

It was bound to happen someday: MemeGen has been ported to use 
example.org. While the original MemeGen scrapes a single blog's RSS feed 
to gather the data used to answer online quizzes, this version attempts 
to scrape the feeds for all of a user's blogs. Bob decides to use this 
site, one day, to find out what race he would be in Tolkien's _Lord of 
the Rings_. He provides MemeGen with the URL for one of his sites.

The first thing MemeGen does is look for an introspection file, which it 
finds from that site's <link rel="service.introspection" /> tag. It then 
sends a request to the URL given in that site's tag. Because it is not 
authenticated, the server decides not to send all of the sites' 
capabilities. MemeGen receives the following:

Example
-------

<feed version="0.3"
   xmlns="http://purl.org/atom/ns#" xml:lang="en">
   <title>Blogs for bob</title>
   <link rel="alternate" type="text/html" 
href="http://manyblogs.org/users/bob"/>
   <author>
     <name>bob</name>
   </author>
   <modified>2004-06-24T19:14:06Z</modified>
   <entry>
     <title>First Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/FirstSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
   </entry>
   <entry>
     <title>Second Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/SecondSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/SecondSite</id>
   </entry>
   <entry>
     <title>Third Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/ThirdSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/ThirdSite</id>
   </entry>
</feed>

MemeGen then requests each site in turn, scrapes their data (possibly 
using feeds as discovered from each page), and presents Bob with the 
happy news that he would be an elf.

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.

- Beecher Greenman

---

From: Ken MacLeod <[email-masked]>
Date: 09 Jul 2004 18:01:08 -0500

>      <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>

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.  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).

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

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

  -- Ken

---

From: Antone Roundy <[email-masked]>
Date: Fri, 9 Jul 2004 17:43:26 -0600

> It's @rel, all over again.
So, we have a few options to choose between--here are those that come 
to my mind:

1) Use <feed> and <entry> for everything, with something like 
<resource-type> or @resource-type to differentiate them.
2) Use <feed> and <entry> for everything, with nothing concrete to 
differentiate them--rely on context somehow.
3) Invent new elements for things that don't fit the model of what a 
<feed> or <entry> is (whatever those models are...).
4) Create a definition of a List Construct and an Entry Construct 
(similar to how we have Date Constructs, Content Constructs, and Link 
Constructs), and then create elements based on those (List Construct = 
feed, introspection..., Entry Construct = entry, site...).

As long as the structure of a List Construct and Entry Construct will 
work for all the kinds of data we want to shove into them, I think #4 
would be my preferred method.  If they're too different from each 
other, I'd prefer #3.

Finally, an idea I don't know that I'd support, but would like to raise 
for comment: would there be value in having all 
List|Entry|Date|Person|Link Construct element names start with a common 
prefix. For example: date-created, date-modified, date-issued, 
list-feed, list-introspection, person-author, person-contributor, 
entry-entry, entry-site...?  It leads to longer names, but MIGHT have 
some sort of "partial understanding" benefits.  I guess this is really 
an extensibility question--if we do this in the core spec, I'd expect 
it would be recommended for extensions, for example foo:list-bar, 
foo:person-bar, foo:date-bar...

Antone

P.S. On a different but similar subject, one might ask why I prefer #4 
but support link/@rel. First, because there are a lot more @rel values 
than there would be List & Entry Constructs. Second, as mentioned 
elsewhere, I'm warming to dumping link/@rel.