Re: [rss-public] Multiple Enclosures (was Re: Clarification v. changes)
- A. Pagaltzis wrote:
> Dave Winer insists that his interpretation of the spec is onlyI tend to agree. I wish he would just come out and state it unequivocally,
> 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.
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.
- --- In email@example.com, "rcade" <rcade@...> wrote:
> --- In firstname.lastname@example.org, "ecomputerd" <ecomputerd@>
> > In addition, it is my opinion that the original RSS 2.0word "recommended"
> > specification referred to the common use of the
> > and not the RFC 2119 definition of RECOMMENDED. Therefore, useof
> > the word "recommended" in the sentence "In all cases, it'sthan
> > 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:same
> 1. channel-title: "If you have an HTML website that contains the
> information as your RSS file, the title of your channel should bethe
> same as the title of your website."forwarding
> 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."names."
> 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.recommendations
> Your advice to use a best practices document for all
> is an interesting one. It would certainly simplify the draft specand
> help implementers distinguish between stuff they MUST know aboutRSS
> 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.