Scott Reynen wrote: > 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.
This is the heart of the problem. The Microformats community has adopted two mutually exclusive philosophies: 1. Scope-less approach to parsing. 2. Requirement to heavily re-use class names. The problem with combining these two philosophies is that they work against each other. If there is no scope when you are parsing, your uF class names are going to start conflicting with one another. The result is that we end up being forced to not re-use class names because of the scoping philosophy. Case in point: hAudio. If we were going the re-use route, we should have re-used 'title', 'summary', or 'description'. Instead, we chose to create a new class name - 'audio-title'. hAlbum is up next. What are we going to call the title of the album? 'audio-title'? We do know that hAudio is meant to be used for the tracks... and that's going to cause a problem. Let's not talk about theoretical, here's a real-world example of the problem: http://www.bitmunk.com/view/media/6011107 In the page listed above, a track is listed before the album. The way the uF markup would have to work is that 'halbum' would be listed first, followed immediately by the haudio definition. Therefore, if we use 'audio-title' for the title of the album, and 'audio-title' for the title of the track, we're going to have a problem. halbum track haudio audio-title Holiday collaborator hcard fn Slick Fifty Seven rel-sample Sample rel-purchase PeerBuy rel-purchase WebBuy published-date 2003-09-16 category Punk duration 4:39 price money currency $ amount 0.65 audio-title The Ghost Of Bonnie Parker **OOPS!*** collaborator hcard fn Slick Fifty Seven Using MFO could fix this problem, although I believe that MFO is a hack. If we think that getting people to understand scoping is a problem - just wait until we need to explain why MFO exists. Try explaining MFO without getting into details about the parsers and how Microformats use a scope-less language design paradigm - these are not light-weight concepts. MFO is a temporary band-aid for the real problem, which was the adoption of two mutually exclusive philosophies. One obvious question at this point is: Why are uFs scope-less? OR: Why are uFs both scope-less and namespace-less? OR: Why are uFs scope-less but require heavy re-use of class names? -- manu _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
