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

Re: [rss-public] Multiple Enclosures (was Re: Clarification v. changes)

Expand Messages
  • James Holderness
    ... I tend to agree. I wish he would just come out and state it unequivocally, but reading between the lines, it seems to me that Dave wants the spec to remain
    Message 1 of 91 , Feb 23, 2006
      A. Pagaltzis wrote:
      > Dave Winer insists that his interpretation of the spec is only
      > one of multiple valid ones. Which seems to mean that the spec
      > effectively provides no guidance and anyone should make up their
      > own mind. So I tried to formulate something that gives guidance
      > without removing this ambiguity which Dave seems to consider very
      > important – clarification, not change.

      I tend to agree. I wish he would just come out and state it unequivocally,
      but reading between the lines, it seems to me that Dave wants the spec to
      remain ambiguous if that's how it has always been. Any clarification that
      made it unambiguous would be considered a change to someone. He's trying to
      avoid having to tell all these companies that have invested "billions of
      dollars" in RSS that their products are now broken as a result of a
      clarification in the spec.

      Take Microsoft for example. Their IE7 aggregator treats titles as plain
      text. Angle brackets and ampersands are just WYSIWYG - there's no markup
      interpretation going on. However, their blogs at MSDN treat titles as
      escaped HTML. They double escape ampersands and angle brackets to prevent
      them being interpreted as markup. Any clarification in the spec that
      unambiguously stated how titles were supposed to be interpreted would break
      one of these two products.

      Of course we're now left with the situation in which we have two RSS
      products, produced by the same company, that won't actually interoperate
      with each other. But at least they can both still claim to be valid
      interpretations of the spec. Everyone's right. Nothing really works. But's
      it's all cool.

    • ecomputerd
      ... word recommended ... of ... than ... same ... the ... forwarding ... names. ... mandatory. ... MUST ... recommendations ... and ... RSS ... Under that
      Message 91 of 91 , Mar 7, 2006
        --- In rss-public@yahoogroups.com, "rcade" <rcade@...> wrote:
        > --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@>
        > > In addition, it is my opinion that the original RSS 2.0
        > > specification referred to the common use of the
        word "recommended"
        > > and not the RFC 2119 definition of RECOMMENDED. Therefore, use
        > > the word "recommended" in the sentence "In all cases, it's
        > > recommended that you provide the guid, and if possible make it a
        > > permalink", in my opinion, does not rise to the level of
        > > RFC2119 "RECOMMENDED".
        > Under that logic, should the word "should" also have less weight
        > it does in RFC 2119? Here's where it appears in the Harvard spec:
        > 1. channel-title: "If you have an HTML website that contains the
        > information as your RSS file, the title of your channel should be
        > same as the title of your website."
        > 2. channel-image: "Note, in practice the image <title> and <link>
        > should have the same value as the channel's <title> and <link>."
        > 3. item-source: "It should be generated automatically when
        > an item from an aggregator to a weblog authoring tool."
        > 4. URI schemes: "Content developers should not assume that all
        > aggregators support all schemes."
        > 5. Roadmap: "Subsequent work should happen in modules, using
        > namespaces, and in completely new syndication formats, with new
        > Shoulds 1 and 2 are minor and could be ignored with little
        > consequence. Should 3 is somewhat important. Should 4 is very
        > important. Should 5 is, by one interpretation, absolutely
        > The draft spec treats 1 and 2 as SHOULDs, omits 3, treats 4 as a
        > and does not contain a roadmap.
        > Your advice to use a best practices document for all
        > is an interesting one. It would certainly simplify the draft spec
        > help implementers distinguish between stuff they MUST know about
        > and stuff they SHOULD know.

        "Under that logic, should the word 'should' also have less weight
        than it does in RFC 2119?" I think it very easily can because, as
        already hinted at, I think the original specification was "not RFC
        2119 aware" (my four-word summary of my paragraph above).

        I agree that cases 1 and 2 are minor, but I'm not familiar with
        their popular conformance (which I think may carry some weight, but
        is not definitive). I do know that the channel title in some cases
        changes frequently (my aggregator optionally generates a warning
        when this happens, that's why I know), it's not clear to me whether
        the title of the "HTML website that contains the same information as
        your RSS file" changes as well. Aside from user convenience/non-
        confusion, it seems that this does not really belong in an
        RSS "specification". I would agree that Case 2 indicates a SHOULD,
        but I cannot imagine why it needs to be that way or why it was
        recommended that way in the first place.

        Case 3 is not useful be in a descriptive specification (as opposed
        to a "Usage Guide", for example).

        Case 4, I think, is worthy of a SHOULD and not a MUST. There seems
        to be no reason why the specification should limit the SCHEMEs. It
        is true that some aggregators will not be able to handle SCHEMEs
        other than "http:", but this seems arbitrary (I'm thinking
        specifically of "ftp:" and "feed:", although "feed:" is not an
        official scheme, it has been implemented in some aggregators), and
        it's very possible other distribution mechanisms (for enclosures)
        would be 1) useful, and 2) specified through alternate schemes.
        Right now, BitTorrent files are specified by the "http:" scheme
        simply because that is the download mechanism of the .torrent file
        itself, but I don't think that should preclude the use of some
        future download method, if it is indeed specified by a unique
        SCHEME. Again, because many aggregators would not be able to handle
        other schemes, it's very useful to label using http: scheme as a
        SHOULD, where anyone deviating from this recommendation should know
        what they are doing.

        Greg Smith
      Your message has been successfully submitted and would be delivered to recipients shortly.