[uf-new] A Download Microformat

[Martin McEvoy]

Hello Scott..

Scott Reynen wrote:
> On [Oct 20], at [ Oct 20] 2:29 , Martin McEvoy wrote:
>
>> The file itself the MP3 not the meta-data surrounding the File
>
> I got that.  What I'm missing is what about the file you want to make 
> machine-readable and why.
The information Exclusively related to the file, Size, type, contributor...
>
>>> And how, specifically, does hAtom's existing enclosure markup fall 
>>> short of answering it?
>>
>> Nothing at all, accept hAtom does not support "enclosure" which I am 
>> sure you are aware of..
>
> Actually I'm not.  The "See Also" section of hAtom says:
>
>> rel-enclosure - how to semantically reference enclosures (e.g. 
>> podcasts) in hAtom
>
>
> http://microformats.org/wiki/hatom#See_Also
>
> And rel-enclosure, of course, supports enclosures.  But I gather it 
> doesn't support everything you'd like to see.  I'm just not clear on 
> what's missing.
I would like to assert that rel-enclosure Is NOT part of the hAtom 
Specification, it is only recommended it falls short in this respect mainly

http://microformats.org/wiki/rel-enclosure#Informative_References

    *  The Atom Syndication Format (http://www.ietf.org/rfc/rfc4287.txt):
          o 4.2.7.2 The "rel" Attribute

  4.  The value "enclosure" signifies that the IRI in the value of the
      href attribute identifies a related resource which is potentially
      large in size and might require special handling.  For atom:link
      elements with rel="enclosure", the length attribute SHOULD be
      provided.

"the length attribute SHOULD be provided" How do I mark the length[size] 
up then?

rel-enclosure in Atom is a link type
http://atomenabled.org/developers/syndication/#link

How do I mark up the title of an Enclosure?

also In the case of  "podcasts" there is more often than not both an 
author of the post, and a contributor typically of a download

rel-enclosure should rightfully be dropped from hAudio proposal because, 
according to the brainstorming
enclosure/acquire only appears 62% of the time in  91 sites
http://microformats.org/wiki/audio-info-brainstorming#acquire

If you remove all the examples that typically related to podcasting both 
speech and audio  a download is a property that occurs 100% percent of 
the time

The podcasting community does not need hAudio to solve its problem 
because almost 100% of the time podcasts appear in the context of a blog 
post, which should use hAtom, the only bit of a podcast hAtom cannot 
solve is the enclosure and its contributor/s  nothing more

The simplest solution for podcasting is to expand rel-enclosure a little 
and use that
>
>> Don't Patronise me
>
> I don't expect you'll believe this, but I didn't intend to do that.
Thank you Scott, I believe you didn't intend it...
>
>> I still dont understand what particular points of the process you 
>> think I have missed
>
>
> It seems to me you've missed the part of the process where you 
> describe the problem:
>
> http://microformats.org/wiki/process#Why.3F
why because Individual publishers of music and Podcasting should use 
hAtom not hAudio because it solves the majority of its needs
>
> I was just trying to help, but it seems clear to me I failed at that 
> the first time.  If this likewise fails, please just pretend I said 
> nothing rather than taking further insult.

;-)


Thanks

Martin
>
>
> -- 
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


-- 
Martin McEvoy

http://weborganics.co.uk/