On Apr 5, 2007, at 9:56 AM, Manu Sporny wrote:
media-info will definitely solve this problem once it is finalized.
That
being said, does that invalidate the need for Music Download
microformat? Based on Stephen and your problem definition for Music
Download, and with your addition below, I think it does.
I think this is backwards. We shouldn't delay solving the simpler
problem until the more complex problem is solved. We should solve
the simpler problem first, and make that solution a modular part of
the more complex solution.
isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this
then? maybe just adding length="198000" or something ?
That is a good, simple solution. 'rel' and 'type' are standard <a>
elements and would aid a browser in recognizing that you are talking
about an MP3 file... Amarok/iTunes could detect an hAtom/hReview combo
with a type="audio/mpeg" link. It would be difficult for it to
recognize
artist/track information - wouldn't it? Wouldn't that have to be
standardized to some degree? While we can use hAtom/hReview to do
this -
it seems a bit like a band-aid... media-info being the real
solution to
this problem. Do you agree or disagree?
I agree that artist and track information are still needed, but
disagree that this in some way reduces the value in reusing existing
standards. We can and should reuse existing standards *and* add
artist and track information.
The Atom standard defines "length" for content, so it wouldn't be a
stretch to imagine that being an optional element of hAtom? The
question
is... do we want to add that to hAtom?
Even before asking that, the question is: is length a property we
need to add at all? It shows up in just over half of surveyed sites,
a bit short of our rough 80% benchmark. We can always add more
later, so we should start as simple as possible. Maybe that means
including length, but maybe it doesn't. We shouldn't be adding
properties just because we can.
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new