Re: [syndication] Re: [DISCUSS] eXtensible Content Syndication (the next step for O CS)

[ian@calaba.com]

I'm stepping into the debate somewhat late, having been on holiday (in
sunny Scotland)

For the past few months I've been working (admittedly, very slowly) on
a successor to OCS version 0.4, taking feedback from OCS users and
also some ideas from the development of RSS 1.0.

It's not complete but here is the current state of my proposal for
version 0.5 of OCS: (There are some typos etc, the main part is the
example of a v0.5 OCS file)

http://internetalchemy.org/ocs/directory-0.5.html

As ever it is purely a proposal, fed by contributions from the
syndication community. Comment and feedback is very very welcome.

Highlights are:

* Cleaner RDF syntax (and it is actually valid RDF to boot :), along
the lines of the RSS 1.0 RDF syntax

* Renaming of channel to service

* Extraction of schedules and formats so that they become more
descriptive and applicable to many services

* Foundations of extensibility. It ought to be possible to use RSS 1.0
modules in an OCS feed.

Where is OCS going?

Well, OCS is slowly being adopted by content producers and aggregators
and there are many people and companies who are using the OCS feeds
from xmlTree.

I see OCS as a leveller. By publishing and consuming OCS feeds every
aggregator ends up with the same channels and services. The
differentiation between aggregators then moves up a level to value
added services, i.e. user interfaces, delivery, personalisation,
ratings, integration etc.

There's a need for the producers of content to be paid for their
services if they desire. I'd like to see the development of a payment
module that allows producers to label their services with the cost and
payment mechanisms supported. Purely optional of course but the end
user has the right to know what to expect.

I'd like also to see meta OCS files, i.e. OCS listings of OCS files.
There's nothing to stop you doing this in OCS 0.4 of course.

Categorisation of services. I won't say any more since we've been talking about it
here for several months.

Description of service interfaces. I'd like to be able to describe
all of Meerkat's flavours in an OCS file so aggregators know how to
get the most out of it (and others like it: 10.am, newsisfree)


Ian


On Monday, August 13, 2001, 5:30:45 PM, burton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> "Duynstee, Teun" <teun.duynstee@macaw.nl> writes:

>> Three comments:
>> 
>> 1) Lets keep really clear if the attributes on the format element should or
>> shouldn't carry a prefix when the XCS namespace is not the default
>> namespace.

> I don't understand what you mean?  You are advocating *not* using attribute
> prefixes... right?

>> 2) What I would really like in a successor to OCS would be a way to
>> deprecate a certain URL. Often, the URLs of feeds change. Of course: rather
>> not, but it happens for both logistic reasons (think www.moreover.com ->
>> p.moreover.com) and marketing reasons (think egroups.com ->
>> yahoogroups.com). Nowadays, aggregators (including end-users of client
>> headline viewers) will only notice this situation when:
>>   a) the feed is discontinued, error message on screen
>>   b) a second feed with identical content shows up
>> 
>> Maybe we could use something like:
>>              <format mimeType="" contentType="" location="">
>>                <deprecated since="" continued-at=""/>
>>              </format>
>> 
>> or maybe something the other way around, where only the current location
>> appears in the list, but carrying a list of previous deprecated locations.

> Good idea.

> This should be a deprecations module though.  We also need an 'until' attribute
> which will detail how long the deprecations will remain in effect for.

>> 3) I think it is important that XCS consumers can see from the listing which
>> feeds are basically the same info, but using a different format. This is a
>> very common situation (check out the Moreover OCS).

> Yes... but this is already possible with OCS.  I want to carry it on into XCS.

>> XCS consumers will want to pick their favoured format and use this. Of course,
>> this is a non-issue if the format element is intended to occur multiple times
>> per feed.  Is that indeed the intention?

> It is in my mind... ;)

>> Would it be usefull then to allow for different languages of the same feed?

> Yeah... I don't know about this.  I have thought about it and it is generally a
> good idea.  The only problem here is that it would require one level of
> nesting.  

> I could/would make the argument that almost all multiple language systems use
> different URLs for the base.

> Something to think about though.

> Kevin