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

Re: [RSS2-Support] Re: RSS 2.0 amendments process?

Expand Messages
  • Bill Kearney
    ... Indeed, the only downside is the semantics behind dc:creator are not very well defined. It can be anything in that string. And I ve seen quite a range in
    Message 1 of 36 , Oct 2, 2003
      > >> I agree. But there is already a widely used alternative:
      > >> dc:creator. Even Jon Udell is using it.
      > >
      > > The problem is that's part of the RSS 1.0 RDF spec, not the 2.0 spec.
      > >
      > Not at all. dc:creator is a Dublin Core element, has nothing to do with
      > RSS 1.0 or even RDF. It's perfectly fine as an extension for RSS 2.0.

      Indeed, the only downside is the semantics behind dc:creator are not very well
      defined. It can be anything in that string. And I've seen quite a range in
      processing the data via Syndic8.

      Thus some RDF folks are beginning use <foaf:maker
      rdf:resource="url/of/author/foaf.rdf"/> instead. The same sort of idea can
      easily be applied to any XML application. That it's commonly used in something
      like RSS-1.0 doesn't mean it's not useful elsewhere.

      The advantage of using stuff in the RSS-1.0 (RDF) fashion is one of
      consistency. The model's pretty robust once you get your head wrapped around
      it's nuances. Making use of resource URLs opens the door to a whole bunch of
      ideas. But alas that's mired in a quagmire of FUD so I suppose we shouldn't go
      there (at least not on /this/ list)

      I'd certainly welcome better efforts to structure author or for that matter
      people info in general.

      Like others here I don't see why yet another style has to be invented for
      contact info. There's been a ton of useful research done in other efforts. Why
      reinvent what they've done? The downsides of reinvention are many. For one, it
      ends up pissing off the people that did all the hard work (just to see it
      imitated; often poorly). It also adds yet another layer of processing
      applications are expected to perform. For stuff like contact info there's such
      a huge body of research that's been done it REALLY seems sort of dumb to
      reinvent it here...

      But that's just my well-informed and battle-scarred opinion, of course.

      -Bill Kearney
    • petite_lapin_blue
      Dear Mr him , ... You are presuming a very narrow usage pattern. And what s wrong with http encoding? ... Adverse is to the point. If you use any type of
      Message 36 of 36 , Oct 4, 2003
        Dear Mr "him",

        On Friday, Oct 3, 2003, at 20:38 Europe/Amsterdam, houghtoa wrote:

        > You missed the point, but worst, are reckless about bandwidth issues.

        You are presuming a very narrow usage pattern. And what's wrong with http

        > "Adverse" is rather strong.

        "Adverse" is to the point. If you use any type of aggregate format you will need a two
        steps process: get a "bill of materials". Then get the content. It would be very
        unfortunate if to get the BOM you need to get the entire content.

        > Surely this was sarcasm. How can you comment that it's just like mail attachments.

        Surely it was. I happen to have some exposure to the inner working of email:


        This doesn't make me an authority on the matter though.

        > You missed the point again.

        Nope. I got your point. But perhaps you didn't get mine. Which is ok. We could agree
        to disagree.

        > As someone else pointed out, if you don't want to use an archiving mechanism
        > then use multiple items, yet another solution for working *within*
        > the current specification.

        Ok. Let me illustrate my "circumstances" more concretely. This will most likely require
        a great leap of faith on your side, but I'm sure you can manage.

        Lets assume that I want to publish a RSS item regarding a forthcoming meeting. The
        meeting is about some random corporate activities. I also spent some time preparing
        supporting materials for this forthcoming event: a document describing the agenda, a
        spreadsheet with some nice pie charts and a presentation outline. Those materials are
        related to this event. They are not random artifacts. Now, if I want to attach this
        material with my RSS item, what do I do?

        (1) I use one enclosure and package all the materials in some sort of archive.
        Workable for sure. But cumbersome. And I'm loosing the information about what's in
        the archive. Instead of a Word document, an Excel spreadsheet and a PowerPoint
        presentation, I now have an amorphous blob. Sure, I could dig into this archive to
        retrieve its content. But then I will need to make the assumption that this archive is
        just a wrapper for its content. And not the content itself. How do I distinguish
        between an enclosure which points to an archive and an enclosure which point to a
        wrapper? This introduce ambiguity of intend.

        (2) I create multiple RSS item for this event: perhaps one for the event itself. And one
        for each document. Something like: here is the event. And here is a document. And
        here is a spreadsheet. And here is a presentation. Workable for sure. But I lose the
        "unity of action". Instead of having one RSS item with some attached materials, I now
        have four different items with nothing to link them together. Sounds like a dead end
        to me.

        (3) I create one RSS item with multiple enclosures. End of the story. Unity of action.
        No ambiguity.




        Why don't you also apply your phenomenal analytical power to the other three topics
        at hand? Would love to hear your personal take on them.
      Your message has been successfully submitted and would be delivered to recipients shortly.