[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceIntrospection: New Examples for Feed-Based Introspection


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