Re: [syndication] Re: generic minimal set desired in a data syndication message?

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

.. still at my mail... but not for long. Let me see if I can clarify some
of the points I tried to make before I drop off for a few days.

On Mon, 21 Aug 2000, Aaron Swartz wrote:

> From the proposal:
> > accessing the _url_to_resource_ would retrieve this message,
> > although you might get a newer/updated version of it. The
> > 'uuid' is a universal identifier that somehow references
> > this specific resource - using a uuid, you'd always get
> > exactly this data set.
> 
> I'm a bit confused, so let me see if I understand:
> 
> The URL points to the latest version of the message, but the UUID points to
> the specific version that's contained in this file. Right?

MOre or less. My explanation/justification is a bit weak here.

The idea is that a URL (here passed as the href attribute value on the
accessInfo element) does not uniquely identify a resource (due to a
variety of issues, such as content-negotiation or time-varying resources),
so you need another identifier to uniquely identify any retrieved
resource.

The 'href'ed URL for the UUID is just a simple-minded idea that, if the
specific UUID-referenced resource is accessible via a simple GET request,
then this could be explicitly given. If it can't, then you'd need to leave
this off.

> > the 'interface' somehow defines
> > how to generically access the Web service that distributred
> > this resouce. The href gives the URI location, the 'type'
> > the type of interface, and 'info' simply lets you know where
> > to go to figure out what to do at this interface. Info
> > would be human-readable, but could be a schema later on...  
> 
> OK: 
> 1) why do we need the URL for the specific version, if it's already in the
> file.
> 2) SOAP and XML-RPC seem like overkill for the UUID. What's wrong with a
> plain old URL? Or URI, if you must.

I don't quite understand (1). As for (2), yes I agree completely - that's
why the interface stuff is separate. The idea is that <interface>
specifies information about some sort of more extensive interface to the
system that produced this message -- which may be completely unrelated
to the URL for the resource or the URL associated with the UUID.

THe idea is that there are two ways you are most likely to want to  
retrieve or reference a syndicated resource, as indicated by
the accessInfo href and the <uuid>:

  a) a URL that simply retrieves the 'most recent' version,
     subject to whatever content-negotiation might occur on the way.
  b) a UUID and (possibly) a more complex URL that uniquely
     identifies and/or retrives exactly this resource.

However, if this resource comes from a service accessible via a rich
protocol, you probably want to tell people about this third way to access
the service. This would be what <interface> does. 

So, <accessinfo> contains both explicit routes to retrieving this
resource plus optional metadata about a generic interface to the
service providing such resources.


> > Note that the
> > 'distribution rules' might simply be a human readable document -
> > since there's no way, in this model (non-ICE) to enforce these
> > rules
> 
> Why is that? I don't see why not.
> 
> >   <keywords separator=",">comma, separated, words ....</keywords>
> >   <category separator="/">a/b/c</category>
> >   <category separator="/">d/e/f</category>
> 
> Oh man, why do you make me do all that extra parsing. What's wrong with
> plain old XML?
> 
> <keywords><k>XML</k><k>separated</k><k>words</k></keywords>

NO reason -- this is only an example of the type of information that seems
to be commonly asked for in these discussion on syndication. Please don't
get too wrapped up in my sometimes awkward notation (in this case the
thing started as an attribute value): what's imporatnt is whether or not
this is an important concept that's worth having in a core syndication
spec. I'd be happy with any suitable notation -- but it only matters if
this turns out to be an important component for a syndicated message.
 
> > this is metadata describing properties of the resource. Pretty
> > general stuff, actually
> [...]
> > this block describes text/content related metadata about the
> > resource.

> What's the difference between stuff in "meta" and stuff in "overview"?

The difference is small, and may not be worth pursuing.. I was looking for
a separation between human language dependent and language-independent
information, since the latter would vary with different language versions
of equivalent resources, while the former might not. This distinction may
not be important. 
 
> That's my first thoughts. More will probably come later. Anyway, thanks a
> lot -- this (I think) is a really important step for syndication. I'm glad
> somebody's doing it.
> 

Thanks for the feedback.  I'm pleased that some others also think this is
worth looking into in more detail.

Ian