RSS and WAP/WML... lessons re HTML and RDF and format divergence?

People are stressing out about their being 2+ flavours of RSS. We should
remember that the story doesn't stop there...

http://www.oasis-open.org/cover/wap-wml.html
and in particular WML 2.0, see
http://www.oasis-open.org/cover/ni2001-08-01-b.html

WML pages were another XML document format that offered a 'site summary'
suitable for phones and PDA browsers. I've not followed the work closely,
but it seems (eg. see some of the punditry lined from the 1st URL above)
that the gravitational pull of (X)HTML was felt, and the format is moving
towards being a profile of XHTML rather than a distinct stand-alone XML
document format. I expect RSS to feel that same pull...

If we're in a 'standing back and taking stock' mood, we should look beyond
the confines of RSS v*.* and consider developments such as WML, and the
design choices that have been made elsewhere.
http://www.wapforum.org/what/technical.htm has some pointers to the
WAPForum work in this area, for example for an XHTML Mobile profile and a
WML 2.0 spec that (as I understand it -- haven't followed this work
closely) bridges the HTML-based recent approach with the WAP/WML 1.0
approach.

So one point I'm making is that WAP/WML is of specific interest, both as a
technology that's in a similar space to RSS (boiled down summaries of Web
content). My other point is just that we should look around at the wider
context within which we're designing and deploying RSS, and see the split
between the RSS flavours in the context of this wider landscape of
multi-format, multi-namespace'd XML in the Web.

Aside: here's a piece I found on RSS, HTML and WAP (and using XSLT to
transform between them):

	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 to use
namespaces etc...)

I think there are some fantastic things we can do with XSLT, to tranform
(*often lossily*) between independently developed XML document formats,
and to lessen the workload of content producers. But we shouldn't rely on
it to get us out of sticky situations that we needn't have gotten into in
the first place. XSLT is a full-on programming language, so *of course* we
can write XSLT computer programs to create docs in one format based on
input from docs in other formats. That's very handy. But it doesn't make
it harmless to run around creating lots of different widely-evangelised
document formats that solve the same problem. If we evangelise RSS 1.0 as
an XML format for 'whats new' pages on web sites, and others evangelise
HTML, and others evangelise RSS 0.9.34147*, and others evangelise WML/WAP
1.0, that creates a confusing, fragmented world for content producers and
tool developers.  The existence of XSLT (ie. the ability to write
XML-centric computer programs) is one tool for making such a fragmented
world less painful, that's all.

The reason I'm happy to evangelise RSS 1.0 is because it isn't
just yet another XML document format. It falls into the family of XML
document formats that stick to the RDF syntactic conventions for
multi-namespace documents. This means that RSS shares a *lot* of common
structure with other RDF-compatible XML-based languages. RDF was designed
so that independently developed RDF vocabularies would play well together.
The general case of independently developed XML formats is different; two
different XML document formats needn't share any conventions beyond the
basics of the elements'n'attributes tree structure (and, hopefully, the
use of namespaces).

There are enough overlapping XML document formats out there that we should
very seriously pause for thought before encouraging the world to adopt yet
another XML document format for Web content. Particularly when it's scope
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 pushing
another XML doc format on the world, without a story for how it fits in
with its neighbouring formats. RDF is just such a story. If folk think the
syntactic cost of using the RDF story are too high, that's ok (and
probably a matter of taste and aesthetics). But they'll need to provide
some other story instead...

Just as WAP/WML has it seems gone done the XHTML modules/profiles route,
RSS via 1.0 has gone down the RDF route. XHTML and RDF are two major
stories for how mixed-namespace convent formats can be gracefully deployed
in the Web. Switching metaphors... WAP's WML as a content format found
itself in orbit around planet XHTML (document centric); RSS imho finds
itself more naturally in orbit around planet RDF (data centric). Both have
an growing toolset, and strategies (XSLT, HTML modules; triples,
namespaces) for mixing indepently developed extensions. And both have an
attractive pull; being a satellite of HTML or RDF is imho much preferable
to drifting freely through (name)space, without any architecture for
(i) playing well with other doc formats (ii) mixing together namespaced
extensions.

XHTML and RDF are pretty compelling stories that address (i) and (ii);
saying, 'just use namespaces and write XSLT computer programs'
is another such story, but one that leaves a scary amount unspecified.
Which namespaces? What kind of computer programs? What structural
conventions do these namespaces share to make it possible to combine them?
Answering such questions is more work than I think we can feasibly manage
in the RSS-DEV and syndication community, except through adopting the
answers being developed for XHTML and RDF. Why go it alone?

Dan


-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Saturday, 7 September 2002 14:09:11 UTC