Re: [uf-new] Closing outstanding hAudio issues
Manu Sporny wrote: The following hAudio issues have been resolved with the latest update to the hAudio proposal (hAudio v0.8). If there are no objections, I'd like to mark all of them as resolved. Seeing no objections, issues 2, 9, 10, 11 and 13 have been resolved. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk Launches World's First Open Music Recommendation Service http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Specification Page is published
On Sat, 2007-11-03 at 11:42 -0400, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio Well done all Thanks Manu the: http://microformats.org/wiki/haudio-cheatsheet Has been updated to the hAudio 0.8 Draft For testing purposes http://weborganics.co.uk/haudio which has been used throughout the hAudio process has also been updated to Version 0.8 A new test case of hAudio in hAtom, designed to be a syndicated format similar to a podcast is available for testing: http://weborganics.co.uk/hypercast single static html file http://tools.microformatic.com/transcode/atom/hatom/http://weborganics.co.uk/hypercast/ Transformation into atom http://feeds.feedburner.com/microformats/HyperCast Transformation into a rss podcast via feedburner Thanks Martin McEvoy We're working on an implementation in Operator and will start evangelizing hAudio use in the coming weeks. For those that are interested in hAudio, please have a look through the page and let us know if there are any outstanding issues with the current proposal. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Specification Page is published
On Sat, 2007-11-03 at 11:42 -0400, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio Just some minor points 1, http://microformats.org/wiki/haudio#Price span class=price should this not be... span class=money ? as per the Currency Proposal http://microformats.org/wiki/currency-proposal and 2. http://microformats.org/wiki/haudio#Item ...No sub-elements should be read from any hAudio contained in a track element should read.. ...No sub-elements should be read from any hAudio contained in an item element Thanks Martin We're working on an implementation in Operator and will start evangelizing hAudio use in the coming weeks. For those that are interested in hAudio, please have a look through the page and let us know if there are any outstanding issues with the current proposal. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Specification Page is published
On 4 Nov 2007, at 00:53, Martin McEvoy wrote: 1, http://microformats.org/wiki/haudio#Price span class=price should this not be... span class=money ? as per the Currency Proposal http://microformats.org/wiki/currency-proposal No. Should the currency microformat be completed, then that class name would be used in addition. As per existing patterns (such as class=author vcard in hReview), you might end up with span class=price hcurrency or something. My view is that with currency still being a proposal, it should not be used in examples. That risks causing confusion and may inadvertently push a sub-optimal currency pattern into mainstream usage without it going through the process. I'd like to see that simplified to the text form of price, ala: span class=price$14.00/span Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio Examples (was: hAudio Specification Page is published)
On 3 Nov 2007, at 15:42, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio I've been through and edited the examples to fix issues with validation and incorrect closing tags. I have the following issues with them: • class=price should not include mark-up from a currency proposal. It could endorse, promote and spread use of mark-up that is later discarded as sub-optimal. I don't think the hAudio spec should advocate use of an unfinished microformat at all. span class=price£1/span should be sufficient for these examples at the moment. • All uses of the ABBR pattern for dates and times should use hyphenated separators. We're still in an accessibility grey spot with regards to the whole thing, but it was noted that splitting dates with hyphens made it acceptable in some cases (2007-11-03 over 20071103). I don't know what the effect is of your new duration abbreviations. It's important that someone with access to the right equipment tests those expansions with assistive technology. If it's appropriate to hyphenate the expansions in the time formats, then they should be. • I'm of the view that whilst use of HTML elements should be neutral wherever possible (SPAN, DIV), use of presentational elements such as BR should not feature in our examples. Some of the examples are using BR to change the presentation. These should be reworked somehow. Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] [hAudio] Contributor as an hCard
On 3 Nov 2007, at 15:42, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio Contributor: “The contents of the element should include a valid hCard Microformat.” Results in: span class=contributorspan class=vcard This is different from the pattern used in hReview for reviewer, which results in: span class=reviewer vcard The hReview form is superior, and already in use. I suggest the hAudio wording be changed to say: A contributor _should_ be an hCard Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
I think hAudio would be clearer to adopt the same pattern, so the second (album) snippet would become: div class=haudio span class=fn albumIn Rainbows/span /div I second that. Makes more sense, is more consistent. Also makes it easier to write a definition for Operator :D ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Sun, 2007-11-04 at 02:08 +, Martin McEvoy wrote: On Sun, 2007-11-04 at 02:00 +, Julian Stahnke wrote: I think hAudio would be clearer to adopt the same pattern, so the second (album) snippet would become: div class=haudio span class=fn albumIn Rainbows/span /div I second that. Makes more sense, is more consistent. Also makes it easier to write a definition for Operator :D Agreed +1 Thanks and can also be expressed as ? div class=haudio span class=fnIn Rainbows/span /div Thanks Martin Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
and can also be expressed as ? div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Examples (was: hAudio Specification Page is published)
On Sun, 2007-11-04 at 02:06 +, Martin McEvoy wrote: On Sun, 2007-11-04 at 01:34 +, Ben Ward wrote: On 3 Nov 2007, at 15:42, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio I've been through and edited the examples to fix issues with validation and incorrect closing tags. I have the following issues with them: • class=price should not include mark-up from a currency proposal. It could endorse, promote and spread use of mark-up that is later discarded as sub-optimal. I don't think the hAudio spec should advocate use of an unfinished microformat at all. span class=price£1/span should be sufficient for these examples at the moment. Much Like the hListing proposal http://microformats.org/wiki/hlisting-proposal#Simple_Listing Agreed In principal although I am unsure of when the proposal adopted the use of class=price as It was previously agreed that we use the currency proposal http://microformats.org/discuss/mail/microformats-new/2007-June/000563.html Although I am not sure if the proposal has changed since then Maybe someone can point out when? Thanks Martin • All uses of the ABBR pattern for dates and times should use hyphenated separators. We're still in an accessibility grey spot with regards to the whole thing, but it was noted that splitting dates with hyphens made it acceptable in some cases (2007-11-03 over 20071103). I don't know what the effect is of your new duration abbreviations. It's important that someone with access to the right equipment tests those expansions with assistive technology. If it's appropriate to hyphenate the expansions in the time formats, then they should be. My Preference for now is simply to use span class=duration4:44/span which I believe is an ISO 8601 time format http://en.wikipedia.org/wiki/ISO_8601#General_principles any use of the abbr design pattern I think should be kept to a minimal in the creation of hAudio, or any new Microformat for that matter. • I'm of the view that whilst use of HTML elements should be neutral wherever possible (SPAN, DIV), use of presentational elements such as BR should not feature in our examples. Some of the examples are using BR to change the presentation. These should be reworked somehow. Ben Thanks Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Sun, 2007-11-04 at 02:49 +, Julian Stahnke wrote: and can also be expressed as ? div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. Are you sure? http://microformats.org/wiki/audio-info-proposal#Multi-part_Podcast_Example something else that need looking at ? Thanks Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: ...It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. A good description maybe this can be added to the wiki? Thanks Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: On Nov 3, 2007, at 8:49 PM, Julian Stahnke wrote: div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Wasn't there a discussion some time back on WHY we shouldn't clobber the fn attribute ie: existing uf's are scopless, and It will cause issues with existing uF's, and a superfluous 'fn' detected http://microformats.org/discuss/mail/microformats-new/2007-June/000575.html David Janes also pointed out that: ...fn isn't available for use (unless item or similar is injected, as mentioned earlier in this thread) http://microformats.org/discuss/mail/microformats-new/2007-June/000576.html this means that if fn exists in a class on its own then it must be wrapped in item or some similar mechanism eg: div class=haudio span class=item span class=fnIn Rainbows/span /span /div hence the decision was to use audio-title as this wouldn't interfere with existing uF's and make the audio-title class name directly attributed as the main hAudio title and wouldn't need heavy markup like the above? the decision to use fn album causes concern for me and is unclear, I understand that hAudio uses this mechanism to suggest fn hAudio type seems a bit rushed and I don't think that this proposal warranted an adoption from audio-title but it seems every one supported it, so there you go as far as I can see we created a new microformat album instead of audio-title. Does this also mean that all haudio must be regarded as an album? how do we state otherwise? Anyway Scott I don't think that anyone exactly agrees with me on the list, so disregard the above :) just my 2 pence worth. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
Scott You were a solid supporter of using audio-title and helped make the decision NOT to use FN ...We can't both re-use property names and ignore the context of those property names. My dog's FN is not my FN, and if the only way for me to make that clear is to use class=pet-name instead of FN, that's what will happen. http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html ? What changed your mind ?, this was the statement that made us support the use of audio-title Thanks Martin On Sun, 2007-11-04 at 04:06 +, Martin McEvoy wrote: On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: On Nov 3, 2007, at 8:49 PM, Julian Stahnke wrote: div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Wasn't there a discussion some time back on WHY we shouldn't clobber the fn attribute ie: existing uf's are scopless, and It will cause issues with existing uF's, and a superfluous 'fn' detected http://microformats.org/discuss/mail/microformats-new/2007-June/000575.html David Janes also pointed out that: ...fn isn't available for use (unless item or similar is injected, as mentioned earlier in this thread) http://microformats.org/discuss/mail/microformats-new/2007-June/000576.html this means that if fn exists in a class on its own then it must be wrapped in item or some similar mechanism eg: div class=haudio span class=item span class=fnIn Rainbows/span /span /div hence the decision was to use audio-title as this wouldn't interfere with existing uF's and make the audio-title class name directly attributed as the main hAudio title and wouldn't need heavy markup like the above? the decision to use fn album causes concern for me and is unclear, I understand that hAudio uses this mechanism to suggest fn hAudio type seems a bit rushed and I don't think that this proposal warranted an adoption from audio-title but it seems every one supported it, so there you go as far as I can see we created a new microformat album instead of audio-title. Does this also mean that all haudio must be regarded as an album? how do we state otherwise? Anyway Scott I don't think that anyone exactly agrees with me on the list, so disregard the above :) just my 2 pence worth. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote: You were a solid supporter of using audio-title and helped make the decision NOT to use FN That's not true. I think you have the order of events confused. ...We can't both re-use property names and ignore the context of those property names. My dog's FN is not my FN, and if the only way for me to make that clear is to use class=pet-name instead of FN, that's what will happen. http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html ? What changed your mind ?, this was the statement that made us support the use of audio-title Nothing changed my mind. I was not at all arguing against FN there, rather for the awareness of context that is necessary to use FN with embedded microformats. And I was arguing for that *after* FN was already discarded, because I thought it was unfortunate we had discarded FN rather than solving the context problem. Right now the necessary context is explicitly written into hAudio ITEM (The element must be processed opaquely). It still doesn't exist in other microformats, but the general consensus (arrived at on the -dev list despite my protest that it's more than a parsing issue) was that we shouldn't address this until it becomes a more widespread (and thus better documented) problem. Maybe it will never become a bigger problem, or maybe hAudio will force the issue. Either way, I'm for solving this problem with more explicit context rather than inventing new synonymous class names (e.g. audio-title) as a means of working around it. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
