Re: [uf-new] [hAudio] fn _or_ album
Hello Scott On Sun, 2007-11-04 at 17:24 -0700, Scott Reynen wrote: No, it indicates the type of audio, not the type of name. There is no joint fn album property; that's two completely separate properties that happen to be classifying the same element. In HTML, one class name has no effect on the meaning of another. FN in HAUDIO *always* means name of audio. Manu and Brian had quite a debate on fn audio (nine days) which started off in the Item/track debate http://microformats.org/discuss/mail/microformats-new/2007-October/001151.html That ended up as the Proposal being ... HAUDIO parts are denoted by ITEM: span class=itemspan class=fnTrack Name/span/span EXAMPLES: Album with two tracks, simple example: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span div class=item span class=fnHokkaido Dream/span /div div class=item span class=fnTokyo Groove/span /div /span Album with two tracks, more detailed: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span span class=item span class=fnTokyo Groove/span abbr class=duration title=PT4M46S4:46/abbr /span /span ... span class=fn albumBest Before 1984/span is not both a track and Album, Its just an album The context in which fn album is used in the above example is pretty much a re-use from fn org where fn album is used to imply that fn type is an album. This is my Axe that I am grinding if: span class=fn albumBest Before 1984/span Is an album and span class=albumBest Before 1984/span is also an Album where are the advantages of using span class=fn albumBest Before 1984/span over just span class=albumBest Before 1984/span ? It seems correct and understandable to simply markup hAudio like this: A track unknown album, detailed: span class=haudio span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span /span a single track known Album, detailed: span class=haudio span class=item span class=albumBest Before 1984/span span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span /span Album with two tracks, detailed: span class=haudio span class=albumBest Before 1984/span span class=contributorCrass/span span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span span class=item span class=fnTokyo Groove/span abbr class=duration title=PT4M46S4:46/abbr /span /span No misunderstandings, and easy to understand. I don't understand what benefits a publisher has using fn album over simply just album Microformats are supposed to use simple conventions and use brief, descriptive class names, sorry about the quotes I am just emphasising my Issue. Thanks Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
No misunderstandings, and easy to understand. I don't understand what benefits a publisher has using fn album over simply just album Microformats are supposed to use simple conventions and use brief, descriptive class names, sorry about the quotes I am just emphasising my Issue. Wouldn’t that be like trying to use just ‘org’ in an hcard to say that something is an organisation? If we model this aspect of haudio after vcard, shouldn’t it behave the same? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 5, 2007, at 7:38 AM, Martin McEvoy wrote: where are the advantages of using span class=fn albumBest Before 1984/span over just span class=albumBest Before 1984/span ? The former indicates the album is the same as the audio (because they have the same name), whereas the latter may just be an album related to the audio. This allows publishers to focus primarily on individual songs or on albums as they do naturally. A track unknown album, detailed: span class=haudio span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span /span That adds an extra layer of container where none really exists. Item of what? We're only talking about a single song here, so why can't a publisher just focus on that song without wrapping a container around it? Not every song even belongs to an album, so it's not just unknown albums this would be forcing publishers to markup; it's also non- existent albums. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
Julian Stahnke wrote: No misunderstandings, and easy to understand. I don't understand what benefits a publisher has using fn album over simply just album Microformats are supposed to use simple conventions and use brief, descriptive class names, sorry about the quotes I am just emphasising my Issue. Wouldn’t that be like trying to use just ‘org’ in an hcard to say that something is an organisation? Doing this is perfectly OK to do in the VCARD format, AFAIK. It would be up to the application to understand that since no other fields are present, the displayable name should be the same value as ORG and the VCARD is about an ORG. If we model this aspect of haudio after vcard, shouldn’t it behave the same? Jeez, this issue just won't die, will it :) How about this proposal: It takes everybody's input into account in this thread and follows the current hCard specification exactly. PROPOSAL: FN is required for hAudio. It is used to identify the name of the audio recording. ALBUM is optional. It is used to identify the name of the album that the audio recording belongs to. If both FN and ALBUM are present and the same, the application MUST deduce that the recording being discussed is an audio album. ALBUM SHOULD NOT exist unless FN is specified. Does that work for everybody? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Mon, 2007-11-05 at 16:33 -0500, Manu Sporny wrote: Martin McEvoy wrote: hAudio is not about TRACKS or ALBUMS by default. hAudio is about an audio recording. This is the fundamental underpinning to hAudio. Although Almost exclusively throughout the entire development of hAudio we have been talking about albums and tracks both in our discussions and in our examples http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services Yes, we talked about albums and tracks, I understand where the confusion started. We're just trying to end the confusion and have a very solid definition for what hAudio is right now. :) These discussions are helpful because others on this list may have been under the same impression. Keep in mind that we also talked about podcasts, top lists, operas, sound effects, multi-disc CD sets and various other things. The one thing that all of these have in common is that they are all audio recordings. haudio is a about nothing specific other than a recording correct? Yes, that is correct. hAudio, in and of itself, is about nothing specific other than an audio recording. We do have the capability to be more specific if we want to by using the ALBUM property. However, if the ALBUM property is not in an HAUDIO, it must be assumed that the HAUDIO is about an audio recording and nothing more. so why not call it hRecording and have done with it?, hAlbum is redundant, too specific, so is hAudio I think? but its too late for that now... Thanks Martin -- 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] fn _or_ album
Martin McEvoy wrote: so why not call it hRecording and have done with it? Because video is a type of recording too... What is hRecording? A video recording or an audio recording? hAlbum is redundant, too specific, so is hAudio I think? but its too late for that now... It's not that it is too late for that... hRecording just doesn't make sense for what we're talking about. You could argue that we could name it: hVideoRecording and hAudioRecording... but then someone would make the argument that the recording part is redundant between the two microformat names... which means we end up with hVideo and hAudio using that line of reasoning as well. This thread is going a bit off track... we are talking about FN and ALBUM. Is everyone comfortable with the idea that hAudio is about audio recordings? -- manu PS: What Scott said is also very accurate... and I agree with him 100%. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams
Alan Slater wrote: An example of a diagram in a potential XHTML-based microformat could look like: div class=os-diagram div id=shape-0 class=shape rectangle span class=labelXSL-FO File/span /div div id=shape-1 class=shape circle span class=labelProcessor/span /div div id=shape-2 class=shape rectangle span class=labelPostScript File/span /div div id=connector-1 class=connector single-arrow a href=#shape-0 rel=from/ a href=#shape-1 rel=to/ /div div id=connector-2 class=connector single-arrow a href=#shape-1 rel=from/ a href=#shape-2 rel=to/ /div /div Note that this microformat can only partially define the appearance of diagrams - additional presentational information has to be provided seperately in definitions that describe how each shape is to be drawn. A more detailed outline of this proposal can be found at: http://www.high-beyond.com/downloads/OpenShapesProposal.pdf http://www.high-beyond.com/downloads/OpenShapesProposal.pdf I'm confused. Why are you trying to do this in XHTML at all, especially when the primary means for displaying Open Shapes content will be graphical and that this will not be directly supported by browsers and you intend to render the diagrams using other technologies like Silverlight? Your paper gives three reasons: 1. The ability to embed diagrams into XHTML pages and retain validity without employing new namespaces etc. What's wrong with OBJECT and IMG? If you want to inline diagram markup inside the same document, you can retain XML validity by mixing XHTML with other XML languages such as SVG. Why is avoiding namespaces such a crucial goal? 2. Relative friendliness for search engine crawlers. Not as friendly as a HTML long description of the same diagram, though. 3. The ability to render something if the content cannot be displayed graphically. Particularly important for accessibility – this should always be a major concern. Well, yes, but can you elaborate on how such markup like your example is going to be meaningful to users of existing user agents and assistive technologies, seeing as your links have no link text and AFAIK no current consuming agent will do anything special with rel=from and rel=to? -- Benjamin Hawkes-Lewis ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 5, 2007, at 4:24 PM, Martin McEvoy wrote: a single audio recording? Again, that depends what you mean by single. If you mean one item, then yes. An album is one piece of audio, a song is one piece of audio, an opera is one piece of audio, etc. If you mean contains no sub-items, then no. But of course that's not true of anything we markup with microformats. Events can be divided into sub-events, organizations into sub-organizations, a list into sub-lists, and so on. But why are you asking? Is there specific audio you're unsure of how to publish with the current hAudio proposal? If it's audio, put it in class=haudio. If it has sub-items, put them in class=item. Beyond that, it gets rather philosophical. Does anything really have meaning beyond the sum of its parts? We don't really need to answer that, so let's not. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
