RSS 2.0 external modules

[Cafonauta]

Hi,
I've done some test with RSS 2.0 feeds. I was interested into the
capability to bring data directly inside the RSS channel.
I though to write an external module with my tags but (if I understood
well the specs) there is no way to reference in my RSS feed a dtd
describing my module. Through the namespace tag I can specify an url
where to find some docs about my tags (docs implementation is left to
the writer).
So, if I extend a feed through a custom namespace, should I write also
the a client-aware of my new tags, right?

So where is the usefulness of this modules?

Thank you in advance

--
Cafonauta

[Andy Dingley]

It was somewhere outside Barstow when bo***@mclink.it (Cafonauta)
wrote:

So where is the usefulness of this modules?

IMHO (incoming rant) there is alomost none. For much the reasons you
describe, it is only usel as an end-to-end protocol between an
extended producer and an extended client. Now if a major producer did
this (maybe a music publisher started including new snippets of music
releases), then the client developers would follow. But small sites
can't extend and expect anyone to notice, and you certainly can't
extend clients in ignorance.

This is why RSS 1.0 is better than RSS 2.0, always will be, and one of
the many reasons why Dave Winer is an idiot.

RSS 1.0 uses the RDF model, not just XML. This has the advantage that
the meta-structure of the document is always parseable, even when it
has been extended. It has little theoretical advantge over XML+RSS for
this (as choosing RSS implies much the same level of implied
structure) but it has a few practical benefits; you can use standard
RDF tools, like Jena, to work with it rather than needing to invent an
application-specific toolset for RSS. Secondly the use of OWL allows
this described structure to be extended in a useful manner, even for
new external modules.
--
Smert' spamionam

[Cafonauta]

Andy Dingley <di*****@codesmiths.com> wrote in message:

RSS 1.0 uses the RDF model, not just XML. This has the advantage that
the meta-structure of the document is always parseable, even when it
has been extended. It has little theoretical advantge over XML+RSS for
this (as choosing RSS implies much the same level of implied
structure) but it has a few practical benefits; you can use standard
RDF tools, like Jena, to work with it rather than needing to invent an
application-specific toolset for RSS. Secondly the use of OWL allows
this described structure to be extended in a useful manner, even for
new external modules.

So It's like I supposed :-(
Three weeks ago I started digging into RSS for the first time and (as
most of the people) I started with the RSS 2.0 which it's so
straightforward. Actually I faced immediately with its limitations.

I want to set up a RSS channel which alerts subscribers whenever some
stocks changes. My idea was to include the stocks names and values
inside the RSS feed so I would need some <stock/> <price/> <value/>
tags...
Right now (before digging into RDF) the only solution I see is to have
a normal RSS feed with a <link> to an xml file containing my stock
values along a dtd describing my grammar and an optional xsl for
clients which needs just to diplay data in html style.

Thoughts?

Bye

--
Davide

[Andy Dingley]

It was somewhere outside Barstow when bo***@mclink.it (Cafonauta)
wrote:

I want to set up a RSS channel which alerts subscribers whenever some
stocks changes. My idea was to include the stocks names and values
inside the RSS feed so I would need some <stock/> <price/> <value/>
tags...

By the sound of it, this is pretty easy ! You're into territory
where only clients with a sophisticated understanding of your specific
changes are expected to make sense of this new information.

So my general rules in this case are as follows:

- Add the new properties in such a way that they don't break any
existing features.

- Support the existing RSS properties so that there is a "sensible"
behaviour if a non-enhanced client encounters them (i.e. add the new
<price> property as a machine-processable property, but also repeat
its value in a human-readable <description>).

- Add the new information in a way that would make sensible addition
to RSS, if this were a core part of it - i.e. add properties as part
of the document (if possible), not as linked attachments outside the
document.
So personally I'd use RSS 1.0 (maybe 1.1) because that's what I
always do. However there's no real reason why you couldn't use 2.0
here.

If you want your <stock> <price> & <value> properties, then just add
them. It's now a trivial piece of XML or XSLT coding to make use of
them in your new clients. In the <description> then give enough
information for a "vanilla RSS" client to give some human-readable
display too. There's no need for your enhanced app to even use this
property, if it can already duplicate the information from the
specific properties.

There's no need to apply an RDF processing model here, as you have a
small number of simple additions and they're each of simple structure.
However if you do want to investigate RDF, then go to the W3C site and
look at the document pack from February 2004. Ignore all documents
earlier than this - the docs were re-written from the ground up and
are much better than their predecessors (congratulations to all
involved).

--
'Ph'nglui mglw'nafh Cthulhu Evesham wagn'nagl fhtagn'