Re: Atom and RDF

On Tue, 12 Oct 2004 06:58:58 -0700 (PDT), Dare Obasanjo <kpako-/[email protected]> wrote:
> 
> --- Danny Ayers <[email protected]> wrote:
> >
> > Lucas Gonze listed the following problems with the
> > enclosure element:
> >
> > 1 It causes users to download big files that they
> > will never listen to
> > or watch, creating pointless overload on web hosts.
> > 2 It doesn't allow us to credit the MP3 host, so we
> > can't satisfy the
> > netiquette of always linking back.
> > 3 For broadband users, MP3s are not big enough to
> > need advance caching
> > in the first place.
> > 4 The required content-type attribute is a bad idea
> > in the first place.
> > 5 The required content-length attribute should not
> > be there.
> >
> > http://gonze.com/weblog/story/5-17-4
> 
> I debunked most of these claims at
> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af
> 
> 1. The RSS 2.0 spec never describes this automatic
> downloading behavior. This was a suggested usage that
> Dave Winer began to evangelize outside the spec which
> as many have pointed out has its flaws.

The spec-linked "use-case narrative" is rather suggestive. If no
automatic behaviour is associated with this element then it isn't
really clear why a separate element is needed rather than a HTML-style
hyperlink in the content. But I guess you're right about this not
really being a format issue, more of a user interface thing - would I
rather have the (possibly unwanted) mp3 today, or (definitely wanted)
mp3 tomorrow.

> 2. This is true, although it did seem like a weird
> special case to me.

I don't know, with aggregate-republish systems this could get quite
common. But whatever, although it's a bit untidy structurally this
could be worked around by using the RSS 2.0 <source> element on the
item, sort of reverting to the pre-Userland semantics of <description>
being the description of an item rather than the item/content itself.
 
> 3. See (1) above
> 
> 4. No it isn't. Client software should be able, to
> decide how to react to the enclosure [e.g. if it is
> audio/mpeg display a play button] without having to
> make additional HTTP requests to the web server even
> if it is just HEAD requests.

Hmm, I'm not sure about this at all. I can see how a button might be
useful, but HTML links don't demand prior notification of the media
type.
 
> 5. Agreed.

Cheers,
Danny.


-- 

http://dannyayers.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/