On Wed, Jun 24, 2009 at 1:51 PM, Thomas Loertsch<[email protected]> wrote: > hi all, > > a question: when contemplating over the feature set of hRecipe it occured to > me that i don't seem to get the rational of mixing vocabularies in all it's > subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary when > people can use rel-tag anyway on any element they want to? likewise for > author and date.
--- When you have a single vocabulary for all microformats you get the benefit of calling a URL in hCard the same thing as a URL in hCalender. If you have an hRecipe on a page with Rel-Tag "cake" that page is inpart about "cake" so a parser that is extracting Recipes get the hRecipe and a rel-tag parser gets the tags too. Had hRecipe called their rel-tags something else, then you´d be doubling-up class values on tags, one for plain rel-tag and one for the hRecipe. So having just 1 vocabulary means that parses can be aware of the formats they know and extract them from anywhere in the page, even if they are within other formats. > if i understand correctly the way meta information is added to the DOM > defines which elements are described. when investigating the use of hRecipe > i often found some top level div containing the recipe marked up with > classes hRecipe and some other vocabulary e.g. <div id="yet_another_recipe" > class="hrecipe vcard">. recipe specific elements where then marked up with > hrecipe vocabulary while the author was marked up as vcard. this seems like > a sensible approach to me. or does it make the job for parsers much harder? Now, it makes it easier for parsers. a vCard is a vCard, even if it's in an hRecipe or standing alone, the semantic data is the same. Instead or re-inventing the wheel each time, existing formats are used. Then hCard parsers don't need to be updated to know how to extract person data out of an hRecipe, etc. I hope that makes sense. You should add this to the Wiki under the FAQs, then we can all iterate on the best answer. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
