Re: [uf-new] hAudio/table incompatibility
On Sat, 2007-10-06 at 11:49 +0100, Martin McEvoy wrote: On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote: Martin McEvoy wrote: On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote: So this simpler proposal makes perfect sense to me. at least someone on the list Is starting to make sense. Oh And thanks for Quoting me out of context.. http://microformats.org/discuss/mail/microformats-new/2007-October/000958.html Criticize the ideas, not the people, please. :) I have been wrestling with the current proposal of hAudio since Manu made his announcement [1] And frankly the current proposal is starting to make less and less sense to me, With each different proposal the concept of hAudio gets more and more vague. and honestly I dont like it at all the way hAudio stands now. What happened to keep it Simple, and *Meaningful*? We are attempting to keep it simple... remember, if we don't have ALBUM and TRACK - we have to have the hAlbum Microformat. hAlbum is an order of magnitude more complicated than what is currently being proposed. What part of the mark-up isn't meaningful to you? Please be very explicit as I'm having a hard time following what part of the hAudio specification you don't like. Preface your statements with This concerns hAudio ISSUE #N... So let Keep it simple eh? PROPOSAL: div class=haudio span class=audio-titleAlbum Title/span span class=contributor vcard[...]Artist[...]/span div class=track1 span class=track-titleTrack One/span [...] /div div class=track2 span class=track-titleTrack Two/span [...] /div /div Notice no need to Reiterate hAudio over and over again, hAudio only=20 needs to be declared *ONCE* because the entire contents *ARE* hAudio Please take a bit more time to outline your objection more clearly. Which one of the hAudio ISSUES is this about? all the general hAudio proposal http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables I'm guessing that you don't like the fact that you must define both TRACK and HAUDIO? The reason that we're doing this is because we might want to re-use TRACK (or whatever we end up calling it) in hVideo. Content has sections: Albums have Tracks Television Series have Episodes DVDs have Chapters Books have Chapters We could end up re-using TRACK to describe DVDs like so: div class=hvideo ... span class=dvdThe Matrix/span ... span class=track hvideoChapter 27: The Lobby/span ... span class=track haudioChinese Audio Track/span ... /div [?] If we don't specify hvideo for the video track and haudio for the audio track, how would the parser determine the difference? We would have ambiguity, which is one of the reasons all of the other Microformats do this as well. If you want to push your proposal above, you will have to make the following arguments: 1. Why Ambiguity is not an issue for TRACK. It is an ambiguity when you couple it with another instance of hAudio , it shouldn't I cause such confusions I don't think. TRACK should be clearly defined as a child element of hAudio for it to contain hAudio seems confusing an unnecessary: haudio track haudio ? hAudio inside hAudio ?... 2. Why we should introduce a new property called TRACK-TITLE. You Have proposed recording, album, track, podcast, position and description 5 new properties ONE reused from hAlbum *Track* the rest !!! You decided from the Issues page I Hope? http://microformats.org/wiki/audio-info-issues First I notice that you have dropped the audio-title property? http://microformats.org/wiki/audio-info-issues#audio-title_Property Only YOU made a vote for changing the current propsal which clearly means to me that only you had an issue with this? +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT) My Proposal Suggests We Keep it I voted Against changing it -1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT) David Janes voted also on this issue +1 for using FN, no clear difference between two so why invent another David Janes 14 August 2007 I would take that as a vote against or changing it entirely My view would be from the *Three* votes we had that this was really a *NON ISSUE* but you changed it any way to reflect your views? 3. Why we should require CONTRIBUTOR to be marked up via a VCARD. It Doesn't Just a recomendation as per the hAudio Spec. I feel the more we bloat hAudio with *not* well thought of semantic class names such as *Album* (a container class or object not a title) ALBUM is not a container class, In your view It Isn't.. In my View IT IS You re used the already discovered meaning of hAlbum I Presume?
Re: [uf-new] hAudio/table incompatibility
So this simpler proposal makes perfect sense to me. at least someone on the list Is starting to make sense. Oh And thanks for Quoting me out of context.. Let's all try to clearly state what we mean without sarcasm and avoiding assumptions about what others mean, in the interest of clarifying disagreement and finding agreement. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
I'm guessing that you don't like the fact that you must define both TRACK and HAUDIO? The reason that we're doing this is because we might want to re-use TRACK (or whatever we end up calling it) in hVideo. Content has sections: Albums have Tracks Television Series have Episodes DVDs have Chapters Books have Chapters We could end up re-using TRACK to describe DVDs like so: div class=hvideo ... span class=dvdThe Matrix/span ... span class=track hvideoChapter 27: The Lobby/span ... span class=track haudioChinese Audio Track/span ... /div If we don't specify hvideo for the video track and haudio for the audio track, how would the parser determine the difference? We would have ambiguity, which is one of the reasons all of the other Microformats do this as well. If you want to push your proposal above, you will have to make the following arguments: 1. Why Ambiguity is not an issue for TRACK. 2. Why we should introduce a new property called TRACK-TITLE. 3. Why we should require CONTRIBUTOR to be marked up via a VCARD. About tracks inside hAudio/hVideo: What about assuming that the track has the same media type as its parent element unless declared otherwise? That way, the following—mentioned before—would thus be possible: div class=haudio ... span class=albumAlbum Title/span ... span class=trackSong Name/span ... /div What does ‘track’ mean in the context of the hVideo format, though? I would assume, from my limited forays into the world of video editing and from DVDs I own, that there can be multiple audio tracks that run in parallel. You can then choose one (‘English’, for example) or even two which then run in parallel (‘English’ and ‘Director’s comments’ on a DVD). The usage of ‘track’ specifically in hAudio (and rightfully so) is a sequential one, though. One track comes after another. So while it shares the same name, it’s (to my mind) an entirely different concept than a track found on a CD. I’m not saying that one shouldn’t use the name track for hVideo—by no means, it seems to be quite valid. But I think it’s dangerous to define ‘track’ _across_ the boundaries of it’s definition in the container it’s used in. Maybe it should not have a definition by its own but only in context with the microformat it is used in. (Same as, for example, ‘boot’—it can either be something you wear on your foot or a part of a car.) Then again, that might be quite confusing. I’m very confused already, for you could also map ‘track’ in hVideo to what commonly is referred to as a ‘chapter’ on a DVD. Which would be against its common usage in everyday language (I think). Maybe I missed a bit that would shed some light on this, but I think this issue needs some clarification. For the record: I’m totally for using ‘track’ in hAudio, I’m just wary of trying to define it in a way that makes it be exactly the same in hVideo as well. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote: What does ‘track’ mean in the context of the hVideo format, though? I think we're getting distracted here. That's a good question for the hVideo discussion, but it's really irrelevant to the hAudio discussion. Audio tracks need to be clearly identified as audio tracks regardless of what happens with hVideo, so let's focus on how to do that and leave hVideo for a separate discussion. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
On 6 Oct 2007, at 8:02pm, Scott Reynen wrote: On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote: What does ‘track’ mean in the context of the hVideo format, though? I think we're getting distracted here. That's a good question for the hVideo discussion, but it's really irrelevant to the hAudio discussion. Audio tracks need to be clearly identified as audio tracks regardless of what happens with hVideo, so let's focus on how to do that and leave hVideo for a separate discussion. Okay. If that’s the case, then I don’t see why ‘track’ could not be just plain text? Secondly, somewhat related, what happens if you stumble upon something like the following: div class=haudio h3 class=albummy album title/h3 by strong class=contributorthe artist/strong ol li class=trackmy track title/li li class=trackmy track title/li li class=trackmy track title/li /ol /div Even though the tracks aren’t marked up as hAudio element and hence have no ‘position’ attribute, should ‘position’ be implied by the position of the track in the ol? (This must, obviously, never happen for an ul.) I think that would make sense and enable some nice, light-weight mark-up that everyone with even the most basic understanding of HTML could comprehend or write (and that is quite parseable as well). (Also, I don’t know if the proposal to allow ‘contributor’ to be plain-text was welcomed or not. Just imagine an hcard in there in case it wasn’t ;)) ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
Julian Stahnke wrote: If you want to push your proposal above, you will have to make the following arguments: 1. Why Ambiguity is not an issue for TRACK. 2. Why we should introduce a new property called TRACK-TITLE. 3. Why we should require CONTRIBUTOR to be marked up via a VCARD. About tracks inside hAudio/hVideo: What about assuming that the track has the same media type as its parent element unless declared otherwise? That is a rule that we could certainly enforce via the parser... and it would reduce the markup that a publisher would have to do. Just to add a bit of implementation detail to your proposal: An hAudio parser would then assume that the contents of TRACK is an hAudio object if it is inside of an hAudio container. This means that any uF markup inside of TRACK could be any of the properties of hAudio. hAudio parsers, when seeing TRACK would create another hAudio object and stuff the properties found in TRACK into the newly created hAudio object for the TRACK. Scott Reynen wrote: What does ‘track’ mean in the context of the hVideo format, though? I think we're getting distracted here. That's a good question for the hVideo discussion, but it's really irrelevant to the hAudio discussion. I was attempting to think ahead to hVideo, but it seems to be causing more confusion than helping. Scott's right... we should concentrate on hAudio. Okay. If that’s the case, then I don’t see why ‘track’ could not be just plain text? We could easily give publishers both options without complicating the parser that greatly. Both of the examples below would be proper uses of hAudio: div class=haudio h3 class=albummy album title/h3 by strong class=contributorthe artist/strong ol li class=trackmy track title/li li class=trackmy track title/li li class=trackmy track title/li /ol /div div class=haudio h3 class=album3 live bands at my local venue/h3 by strong class=contributorvarious artists/strong ol li class=track span class=recordingfirst track title/a by span class=contributorfirst artist/span /li li class=track span class=recordingsecond track title/a by span class=contributorsecond artist/span /li li class=track span class=recordingthird track title/a by span class=contributorthird artist/span /li /ol /div Even though the tracks aren’t marked up as hAudio element and hence have no ‘position’ attribute, should ‘position’ be implied by the position of the track in the ol? My thoughts are that it should be... but with the ability to override the li numbering scheme. What happens if somebody only wants to list 3 of the items in the album... song 3, 5, and 8? It should also be noted that the POSITION and DESCRIPTION concepts are disputed additions to the proposal. I still need to go back through and re-analyze the examples to prove that there is enough evidence in the examples to add POSITION and DESCRIPTION to hAudio. PODCAST is disputed by Martin and since I'm the only person that is backing it based on the examples, it will probably be dropped unless somebody else wants to see the ability to mark up PODCASTs via hAudio. It also seems that RECORDING (was audio-title) is a disputed name change, per Martin. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
On Oct 6, 2007, at 4:54 PM, Manu Sporny wrote: PODCAST is disputed by Martin and since I'm the only person that is backing it based on the examples, it will probably be dropped unless somebody else wants to see the ability to mark up PODCASTs via hAudio. That's assuming those who don't want a podcast class don't want to be able to markup podcasts, which in my case is a false assumption. I don't want a podcast class because I think we can markup podcasts without it. Specifically, hAtom + hAudio = a podcast. If you see something missing there, please clarify what exactly. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
div class=haudio h3 class=albummy album title/h3 by strong class=contributorthe artist/strong ol li class=trackmy track title/li li class=trackmy track title/li li class=trackmy track title/li /ol /div div class=haudio h3 class=album3 live bands at my local venue/h3 by strong class=contributorvarious artists/strong ol li class=track span class=recordingfirst track title/a by span class=contributorfirst artist/span /li li class=track span class=recordingsecond track title/a by span class=contributorsecond artist/span /li li class=track span class=recordingthird track title/a by span class=contributorthird artist/span /li /ol /div I think that, if you want to use hAudio properties inside a track, it actually must be an hAudio element. It must not be an hAudio element if you *only* want to use plain-text. Same for contributor with regards to hCard. Would seem most sensible to me. Even though the tracks aren’t marked up as hAudio element and hence have no ‘position’ attribute, should ‘position’ be implied by the position of the track in the ol? My thoughts are that it should be... but with the ability to override the li numbering scheme. What happens if somebody only wants to list 3 of the items in the album... song 3, 5, and 8? In that case, one would either use an unordered list (and have no numbering) or just use a full-blown haudio element and specify the position via the position property as that would *always* override any implied formatting. Implied formatting should accommodate for the most common use cases and be kept simple, I think. It’s the same with implied fn formatting. It works fine in most cases, and if one wants something more fancy, one just uses given- name and family-name etc. Note the use of haudio on the lis, I’m using properties of haudio instead of plain-text, so a new nested haudio element should be required imho. That would result in the following mark-up: div class=haudio h3 class=album3 live bands at my local venue/h3 by strong class=contributorvarious artists/strong ul li class=track haudio span class=position1/span span class=recordingfirst track title/a by span class=contributorfirst artist/span /li li class=track haudio span class=position4/span span class=recordingsecond track title/a by span class=contributorsecond artist/span /li li class=track haudio span class=position8/span span class=recordingthird track title/a by span class=contributorthird artist/span /li /ul /div Your example brings up something new; the various artist album case. From common sense I’d say one should be able to omit the contributor in that case. The parser then should assume it is a various artist album and either say ‘various artists’ (less colloquial, obviously ;)) and/or, if available, construct it from the contributors in the ‘track haudio’ elements. The decision about what to do/display would then be in the hands of the person using the parser for his specific project. I’m aware though that this leads to a dangerous path of assumptions and implications. It may be common sense and thus not very complicated for *me*—but someone else may think differently. Then again, it *really* makes sense to me. But I think we really need some more opinions on this case. PODCAST is disputed by Martin and since I'm the only person that is backing it based on the examples, it will probably be dropped unless somebody else wants to see the ability to mark up PODCASTs via hAudio. That's assuming those who don't want a podcast class don't want to be able to markup podcasts, which in my case is a false assumption. I don't want a podcast class because I think we can markup podcasts without it. Specifically, hAtom + hAudio = a podcast. If you see something missing there, please clarify what exactly. I haven’t given that case a lot of thinking, but I really like that solution. It even mirrors the technical definition of a podcast and makes it digestible by the whole toolchain I image one would want to use on it. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] I propose a new microformat for poems.
From: Michael Walker [EMAIL PROTECTED]
div class=poem
p class=verse
Standing by the roadside,br /
A tall dark man,br /
Wore a long brown coat,br /
Stood in the rain.
/p
I've never been keen with using breaks.
A
more semantically correct answer is provided with XHTML 2.0 where a
line element is defined so that awful breaks aren't required in things
like poems.
If they were used, then the poem would look like this:
p class=verse
lStanding by the roadside,/l
lA tall dark man,/l
lWore a long brown coat,/l
lStood in the rain./l
/p
Until such code is supported though, a modified form can be used
p class=verse
span class=lStanding by the roadside,/span
span class=lA tall dark man,/span
span class=lWore a long brown coat,/span
span class=lStood in the rain./span
/p
with a style of
.l { display: block; }
It's bulkier than just having breaks, but it gives warm fuzzies to the the
semantic leprechaun within me.
--
Paul Wilkins
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio position and description properties
Most of the day today was spent re-analyzing all of the music service and podcast websites in audio-info-examples using Microformalyze. The raw analysis data is available here: http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files The analysis is available here: http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts The new analysis shows very strong support for POSITION. This property is displayed in 70.73% of 41 music service websites analyzed and 100% of the 8 podcast websites analyzed. There is also enough support to meet the 80/20 rule for DESCRIPTION. This property is displayed in 39.02% of 41 music service websites analyzed and 100% of the 8 podcast websites analyzed. PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since there are enough examples to warrant their inclusion into the Microformat. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio position and description properties
PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since there are enough examples to warrant their inclusion into the Microformat. I think you’re right and they both make perfect sense. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
