2. My goal is to drasticallly reduce the barrier to syndication. Its easy to add a couple of tags into an HTML document. It much harder to get programming resources to create RSS for an HTML developer,and to manage two different files.
Browsers would NOT generally interpret RSS tags and mark them up UNLESS the page author wanted them too by applying a CSS class to them. Markup for web browsers is HTML, and markup for aggregators is in RSS 2 (I don't think RSS 1 can work in this manner). The author still controls what content is syndicated, as conttent not within RSS item tags will not be interpreted by RSS user agents like Radio etc.
This is in the spirit of the W3 recommendations for XHTML and modularization. The most well known example is RDDL http://rddl.org/. Mark up for browsers and other user agents for humans is in HTML. Markup for programs which do something other than present the information to the user (in this case, pointing to resources associated with a namespace, like XML schemas, sample instance documents, etc)
Browsers would not be responsible for checking such pages for updates -- they just treat them as HTML pages. But the same URI can be copied into an aggregator, and the same document interpreted by an aggregator. This is a totally different approach than marking up an RSS document with CSS in an aggregator. And it would be very easy to update aggregators to do this -- they just ignore some content.
I like RDF and RSS 1.0, but for this type of application (web designer editing a document in dreaam weaver etc with existing tools), I think RSS 2 (preferably with a namespace as being proposed) shines. Tim Bray tried to reformulate RDDL as RDF a few months ago and decided to stick with XHTML+(the existing RDDL xml elements) because it was much easier to edit. RDDL and RSS are IMO close parallels although they have different purposes.
Doug Ransom Danny Ayers wrote:
It's certainly an interesting idea, but I'm curious about where this is going. It sounds like the aim is towards one-doc-fits-both and one-reader-fits-both, or at least that they're interchangeable. Will this actually get the best of both worlds? What will be the difference at each end? The browser will be able to understand RSS tags and mark them up appropriately - to some extent that is already possible - see http://webaccess.mozquito.com/features/index.xml and look at the source. At the other end we have the subscription angle - in effect asking a browser (with some organisational ability) to periodically check pages for updates. Isn't this likely to be a bit heavy on bandwidth? But putting implementation details aside, why might we want to do this? I suppose the reason for all this is the blog, or rather a specific content management style that involves frequent creation of small pieces of content. Personally I'd hesitate to just fling RSS and XHTML together and hope for the best - the result could easily be loss of the benefit of the metadata and just a slower form of content browser. I think the power is more likely to come from enhancing the content/meta divide rather than reducing it. There may be a Browser NG at the end of this, but before propagating software that may encourage the inefficient use of resources, I suggest the idea is mulled over a little... Cheers, Danny.-----Original Message----- From: Doug Ransom [mailto:doug.ransom@alumni.uvic.ca] Sent: 27 April 2003 17:39 To: syndication@yahoogroups.com; RSS-DEV Cc: Dave Winer Subject: [syndication] Time for XHTML-RSS? Doug Ransom wrote: The more I think about this, the more I like it. I am thinking of writing it up, unless I can convince those working on the RSS RFC to adopt this. I think this should happen concurrently with the addition of namespaces to RSS 2 (whatever flavour that results in), becuase aggregators would be able to use the same code to read RSS 2+ namespace, and XHTML+RSS 2+namespace. The only difference from the current RSS 2.0 in processing is they would need to: - find the first channel it the document instead of requiring channel be the first element of the document. - ignore markup (but not text content) from tags that aren't known RSS modules. This is in the spirit of the concept of descriptive markup of XML documents (as opposed to structured data), and just ignoring markup you don't care about. How the aggregator developers feel? Doug RansomFor really simple syndication, simpler even than Really Simple Syndication (RSS 2), why not define a syndication module for html? http://www.w3.org/TR/xhtml11/ In the following example, all text content within elements from an rss namesapce is syndicated by aggregators after removing tags (but not text) from their children: <html> <head> <rss:channel xmlns="a new namespace"> whatever elements you need</rss:channel> </head> <body> <rss:item><h2><rss:title>My Item</rss:title></item> Date:<rss:date>2003-20-01</rss:date> <rss:description>Today we went <blink>fishing</blink></rss:description>down at the wharf. 100 more lines blah blah. </rss:item> <table><tr><rss:item><td><rss:date>20040432</rss:date><td><rss:title>HTMLAmateurs use tables for layout</rss:title></td><td><rss:description>whatever you think about css</rss:description> is of no consquence to elvis</td> </item></table> </body> The first description would show up in an aggregator as "Today we went fishing", because the blink tag would be stripped out. The rss elements would not be noticed by users with web browsers unless theauthor provided a CSS to display the rss elements. This allows for single source html and RSS without fiddling with web server content-accept, tying to convert one document format to another, etc. And it can be converted to RSS 2.0 or 1 with a remarkably simple program by the aggregator. The RDDL module uses a similar technique for documenting XML namspaces in a machine usable and human use in a single source. Thoughts?-- Doug Ransom Hate spam & pop ups? Try Mozilla for web/ëmail. Its free. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
-- Doug Ransom Hate spam & pop ups? Try Mozilla for web/ëmail. Its free.