Re: RSS and WAP/WML... lessons re HTML and RDF and format divergence?
- --- In rss-dev@y..., Dan Brickley <daniel.brickley@b...> wrote:
> People are stressing out about their being 2+ flavours of RSS. We
> remember that the story doesn't stop there...I have a feeling that introducing yet more concepts won't necessarily
> and in particular WML 2.0, see
help in this situation, though I know where you're coming from and
the point is good.
> WML pages were another XML document format that offered a 'sitesummary'
> suitable for phones and PDA browsers. I've not followed the workclosely,
> but it seems (eg. see some of the punditry lined from the 1st URLabove)
> that the gravitational pull of (X)HTML was felt, and the format ismoving
> towards being a profile of XHTML rather than a distinct stand-aloneXML
> document format. I expect RSS to feel that same pull...beyond
> If we're in a 'standing back and taking stock' mood, we should look
> the confines of RSS v*.* and consider developments such as WML, andthe
> design choices that have been made elsewhere.and a
> http://www.wapforum.org/what/technical.htm has some pointers to the
> WAPForum work in this area, for example for an XHTML Mobile profile
> WML 2.0 spec that (as I understand it -- haven't followed this workboth as a
> closely) bridges the HTML-based recent approach with the WAP/WML 1.0
> So one point I'm making is that WAP/WML is of specific interest,
> technology that's in a similar space to RSS (boiled down summariesof Web
> content). My other point is just that we should look around at thewider
> context within which we're designing and deploying RSS, and see thesplit
> between the RSS flavours in the context of this wider landscape ofto
> multi-format, multi-namespace'd XML in the Web.
> Aside: here's a piece I found on RSS, HTML and WAP (and using XSLT
> transform between them):to use
> http://www.webreference.com/xml/column15/ (for html)
> http://www.webreference.com/xml/column16/ (for WAP)
> Transforming RSS into HTML and WAP I
> The actual transform being at
> http://www.webreference.com/xml/column16/rss2wml.xsl (doesn't seem
> namespaces etc...)tranform
> I think there are some fantastic things we can do with XSLT, to
> (*often lossily*) between independently developed XML documentformats,
> and to lessen the workload of content producers. But we shouldn'trely on
> it to get us out of sticky situations that we needn't have gotteninto in
> the first place. XSLT is a full-on programming language, so *ofcourse* we
> can write XSLT computer programs to create docs in one format basedon
> input from docs in other formats. That's very handy. But it doesn'tmake
> it harmless to run around creating lots of different widely-evangelised
> document formats that solve the same problem. If we evangelise RSS1.0 as
> an XML format for 'whats new' pages on web sites, and othersevangelise
> HTML, and others evangelise RSS 0.9.34147*, and others evangeliseWML/WAP
> 1.0, that creates a confusing, fragmented world for contentproducers and
> tool developers. The existence of XSLT (ie. the ability to writefragmented
> XML-centric computer programs) is one tool for making such a
> world less painful, that's all.I do agree with you here, strongly. XSLT was never meant to be a way
of technically resolving political differences. Of handling multiple
versions of what should be one spec, because the players aren't
willing to get together in the interests of the user community (and I
know, very well from my own personal experience the difficulties
inherent with this situation, BTW).
> The reason I'm happy to evangelise RSS 1.0 is because it isn'tXML
> just yet another XML document format. It falls into the family of
> document formats that stick to the RDF syntactic conventions forcommon
> multi-namespace documents. This means that RSS shares a *lot* of
> structure with other RDF-compatible XML-based languages. RDF wasdesigned
> so that independently developed RDF vocabularies would play welltogether.
> The general case of independently developed XML formats isdifferent; two
> different XML document formats needn't share any conventions beyondthe
> basics of the elements'n'attributes tree structure (and, hopefully,the
> use of namespaces).And I agree with you here. But the same difficulties that will occur
in selling RDF for RSS will occur for other XML vocabularies. We need
to learn how to sell RDF.
> There are enough overlapping XML document formats out there that weshould
> very seriously pause for thought before encouraging the world toadopt yet
> another XML document format for Web content. Particularly when it'sscope
> and role is so ill-defined (we never really say clearly what RSS is*for*,
> to distinguish it from XHTML, WML, even SVG...). I'm unhappy pushingfits in
> another XML doc format on the world, without a story for how it
> with its neighbouring formats. RDF is just such a story. If folkthink the
> syntactic cost of using the RDF story are too high, that's ok (andprovide
> probably a matter of taste and aesthetics). But they'll need to
> some other story instead...route,
> Just as WAP/WML has it seems gone done the XHTML modules/profiles
> RSS via 1.0 has gone down the RDF route. XHTML and RDF are two majordeployed
> stories for how mixed-namespace convent formats can be gracefully
> in the Web. Switching metaphors... WAP's WML as a content formatfound
> itself in orbit around planet XHTML (document centric); RSS imhofinds
> itself more naturally in orbit around planet RDF (data centric).Both have
> an growing toolset, and strategies (XSLT, HTML modules; triples,have an
> namespaces) for mixing indepently developed extensions. And both
> attractive pull; being a satellite of HTML or RDF is imho muchpreferable
> to drifting freely through (name)space, without any architecture fornamespaced
> (i) playing well with other doc formats (ii) mixing together
> XHTML and RDF are pretty compelling stories that address (i) and
> saying, 'just use namespaces and write XSLT computer programs'unspecified.
> is another such story, but one that leaves a scary amount
> Which namespaces? What kind of computer programs? What structuralcombine them?
> conventions do these namespaces share to make it possible to
> Answering such questions is more work than I think we can feasiblymanage
> in the RSS-DEV and syndication community, except through adoptingthe
> answers being developed for XHTML and RDF. Why go it alone?From your statement, my interpretation is that the RSS group
shouldn't try and derive yet another XML format that will become
versioned and inconsistent and confusing, and instead should use RDF,
which provides the schematic rules that ensure that different
instances of the RSS are compatible, and that the RSS fits into a
larger scheme of related data. I agree.
You know this. I know this. All (some supreme being or not as the
case may be)'s children know this. But how do we make it attractive
and tasty for a group of people who don't give a hill of beans about
interoperability with either XHTML or RDF?
This isn't an issue of "If you build the spec, they will come."
I had a person ask a question about this issue this week that I
found to be probably the perfect question for demonstrating the core
confusion about RDF. Opened a whole new viewpoint for me, and has
made the debates worthwhile. This person isn't an RDF person, could
care less about RDF, but the question was so strongly relevant. I
know for a fact that you, Dan, would look at this and immediately
know that it pertains to the whole striped RDF/XML, node-edge-node
issue, the very core of RDF (question in comments at
http://weblog.burningbird.net/archives/000516.php). We answer the
question to this person's satisfaction, we'll answer it to a lot of
Personally, I love the push-back. It's extremely rewarding.
However, into the discussion about the goodness of RDF, the real
world intrudes: Dave "freezing" RSS 2.0, and folks in this group
saying "Well, there will always be two RSS, we'll use XSLT -- better
we'll use XSLT to generate RDF so there will be three
I can't do anything about Dave, though I tried as late as today. But
if we can open up a convesation with the weblogging community, he
does have to listen to them if he won't listen to me or this group.
If we can get buy-in from Blogger, and Movable Type, and Syndi8, and
Newsisfree, and AmphetaDesk, and so on then we have influence. He
Which means if the group continues with RDF, it will have to answer
when people ask why about each specific use of same.
As for this group -- it needs to make a commitment about direction in
regards to RDF, rather than following this "sometimes you feel like
an RDF, sometimes you don't". This is confusing.