Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • p2psmoke
    ... should ... I have a feeling that introducing yet more concepts won t necessarily help in this situation, though I know where you re coming from and the
    Message 1 of 2 , Sep 7, 2002
    • 0 Attachment
      --- In rss-dev@y..., Dan Brickley <daniel.brickley@b...> wrote:
      >
      > 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
      >

      I have a feeling that introducing yet more concepts won't necessarily
      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 '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.
      >

      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'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).
      >

      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 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?
      >

      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
      people's satisfaction.

      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
      transformations".

      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
      will listen.

      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.

      Shelley


      > Dan
      >
      >
      > --
      > mailto:danbri@w...
      > http://www.w3.org/People/DanBri/
    Your message has been successfully submitted and would be delivered to recipients shortly.