[uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allowfor links to streaming files

Tantek Celik tantek at cs.stanford.edu
Mon Aug 18 10:05:27 PDT 2008


Apologies for top-posting. BlackBerry email UI does not allow quoting prev email & adding below.

In short: I agree w Manu, the intent of rel-enclosure is to apply to the streaming case as well.

If we change:

" that hyperlink is intended to be downloaded and cached"

to:

"  that hyperlink is intended to be downloaded (and/or streamed) and cached (and/or buffered)"

that should be sufficient to resolve this issue.

Thanks,

Tantek

-----Original Message-----
From: Manu Sporny <msporny at digitalbazaar.com>

Date: Mon, 18 Aug 2008 12:54:09 
To: For discussion of new microformats.<microformats-new at microformats.org>
Subject: Re: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow
	for links to streaming files


Martin McEvoy wrote:
> Issue D4: 2008-01-10 [1]
> 
> Raised by Andy Mabbett <http://microformats.org/wiki/User:AndyMabbett>
> in 
> (/http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html/)
>
> I do however agree that rel-enclosure IS unsuitable for some types of
> files such as audio streamed directly from a server.

I disagree, Martin. rel-enclosure is suitable for any type of file,
"static" or "streaming", but my interpretation of rel-enclosure could be
wrong.

I believe that Andy was taking issue at the definition of rel-enclosure:

"By adding rel="enclosure" to a hyperlink, a page indicates that the
destination of that hyperlink is intended to be downloaded and cached."

Take note of the "intended to be downloaded and cached" part of the
specification. The term "cached" is problematic because some would
understand that in the sense that it is "stored forever", others would
understand it as "stored for an undetermined period of time, as a whole
or as a part of a whole."

I lean towards the second definition, which results in rel-enclosure
being suitable for any digital file format (static file or dynamic
stream). Afterall, you must /download/ the link in order to do anything
with the data and that data must be /cached/ somewhere on your computer.

So, we either need to agree that this is a non-issue and rel-enclosure
is suitable for static and streaming files, or we need to create a new
concept, like rel="download".

My preference is to resolve that rel-enclosure is applicable to both
static and streaming files and note the decision on the rel-enclosure
wiki page.

> I would like to Recommend that this issue should be closed, pending
> further examples.

I don't believe the problem with this issue to be one of more examples,
but one of interpretation of the rel-enclosure specification.

I propose we:

Resolve to accept that rel-enclosure can be applied to both static and
streaming files and note the decision on the rel-enclosure wiki page.

-- manu

_______________________________________________
microformats-new mailing list
microformats-new at microformats.org
http://microformats.org/mailman/listinfo/microformats-new



More information about the microformats-new mailing list