[no subject]

[Ian Graham <ian.graham@utoronto.ca>]

I've been following the syndication discussion for a few weeks now, and
also looked over some (but not all) of the archived notes. The following
is my somewhat biased sumary of the discussion, a brief mention of my own
interests in this, and some rough outlines of some ideas I've been mulling
over.

First, the discussion seems to revolve around three related but probably
separable issues:

  a) an XML dialect for exchanging syndicated data
  b) how to query a syndication server, with the 
     discussion focussing on an XML dialect for 
     doing so.
  c) how to set up automated push/pull syndication schemes.

MY feeling is that b) and c) should be discussed on this list, but that
the details of XML-based implementations should be discussed elsewhere
(XML-RPC or SOAP groups), as Edd more or less said in a previous letter
[1]. However, some issues are relevant here. For example, simple URLs can
themselves code many standard queries, and it might make sense for a
syndication message to contain URLs referencing standard queries related
to that message (e.g., get most recent version of this resource). Also,
some issues related to automated push/pull will likely require extra
information in any messages.

As for (a), my biased summary of the discussion to date is:

  "a whole bunch of people want to syndicate a variety
   of data types, but can't quite agree on a common
   tools set (modularized DTDs, namespaces. etc.), 
   a set of relevant tags/data, or the reason for 
   syndication (e.g., exchange summary/metadata only,
   or exchange richer data)."

For example, some want to use RSS to syndicate site summaries/metadata,
ScriptingNews for content syndication, and outLiners for (I think)
'richer' content syndication than is possible with ScriptingNews. My own
interests are to allow syndication of the full text of news articles [
e.g., the type of stuff in an NITF (http://www.nitf.org) or XMLNews
(www.xmlnews.org) file], and also distribution of details of public event
announcements (such as concerts, conference schedules, etc.but with
detailed descriptions of the events).  Finally, there is the whole ICE
effort (Information Content Exchange; www.icegroup.org), an industrial
consortium developing a content-exchange protocol, with features some
would like to use, but which seems (to me) a mix of content exchange and
RPC-like issues, and a bit more 'heavy-weight' than desired of an RSS
successor  (I admit to not having looked at ICE closely). On top of this,
we all seem to be assuming different business / use cases for this data --
so it is no wonder it is difficult to get a concensus on approaches and
features.

I think it would be useful to step back and review the different ways in
which syndication data is/will/could be used, and establish some example
use cases to work forward from. Some really rough ones (that I made up for
discussion purposes only) might be:

  * distribute web site/page summaries -- reason:
    summaries posted in a syndicate subscriber's site
    will drive user's back to the originator's site.
    (cross marketing)

  * distribute news article summaries -- reason: as
    above, but data content may differ. Other reasons?
    (e.g., sale of syndicated summary data to a consumer?)

  * distribute full text of news articles -- reason: for
    synchronization of news content across multiple 
    sites (e.g., across an organization, where portal sites
    are run by different units). 

  * distribution of event information (conference, concert,
    etc.) reason: reliable synchronization of 'events'
    calendars; improved, reliable marketing of event 
    information across different public calendaring systems.

  * distribution of full web article content. Reason: 
    time limited sale/distribution of syndicated content 
    with licensed consumers (e.g., information portals, etc.)

  * re-distribution of summaries/content: aggregator collects 
    syndicated data from multiple sites and redistributes a 
    composite set of syndicated data.

If we could find some place to post these and build up a collection, that
would serve as a useful reference for future work.

At the same time, I think that part of the problem can be handled by
breaking the problem down into message layers, and figuring out what can
be agreed-upon in the different layers. I can imagine three:

    a) basic transport/assembly (i.e., date when entire 
       message was assembled for transmission; info about 
       place assembled message comes from)
    b) content data. Since a single message might have
       message parts (like multiple RSS parts) each content
       part would have two components:
        i) generic part metadata (assembly date for
           message, last-modified date, info about provider;
           URL references to provider; URL referencing 
           this message; ....) This would be data common
           to any type of syndicated data.
       ii) part-specific metadata and content. This would
           be any data (metadata and explicit content) that
           is specific to the type of syndicated data being
           sent. 

Obviously you wouldn't need all of this in all cases, but I think,
by looking at the use cases, it is clear that they could all be
useful in one or more of these instances. Also, this structure
would make it possible to distribute different types of syndicated
data in the same overall wrapper, which might have some advantages.

But, of course, the whole thing should be simple -- I agree strongly
with Dave that the goal should be a syntax that is easy to use,
understand, and code for.  Ideally it should also be easily 
upward compatible with existing standards, although whether or not
that is possible will come out in the analysis. In particular, I don't
know how this fits in with ICE (any thoughts?)

So, that's enough for one message. I trust that these observations
will prove useful.

Best wishes  --

Ian
--
[1]           http://www.egroups.com/message/syndication/269?&start=242
NITF          http://www.nitf.org
XMLNews       http://www.xmlnews.org
RSS 0.91      http://my.netscape.com/publish/help/mnn20/quickstart.html
ScriptingNews http://davenet.userland.com/1997/12/15/scriptingNewsInXML
ICE           http://www.icestandard.org/
--
Ian Graham ............................ http://www.utoronto.ca/ian/
i a n   d o t   g r a h a m    a t    u t o r o n t o   d o t   c a