Creating 80%-or-more overlapping formats is evil. XOXO can be made to do anything - and this most especially. So you have to change the output code a tad more to apply it than you do for some other formats - what does that hurt? The resulting code is much better structured anyway... -- Singpolyma
On 11/25/06, Aaron Gustafson <[EMAIL PROTECTED]> wrote:
Manuel Simoni wrote: > Cool, I think it's isomorphous... The "p-v" corresponds to > "hcustomfield", the "property" to "hcustomfield-name" and the "value" > to "hcustomfield-value". Exactly, like I said, we were trying to keep it simple. >> I don't know if you think what we've put together would be applicable >> (we were trying to keep it as simple as possible, hence the short >> names), but I agree this is something that would be really nice to >> have and should be an aspect of microformats, possibly existing as a >> microformat unto itself which can be combined with other ones >> when/where it makes sense to create subformats specific to a >> particular use (for instance, wine, televisions, cars, etc. all have >> custom fields in the product world, most of which are consistent >> within their category and could combine a property-value construct >> with a standard hProduct to make a nice subformat -- perhaps a better >> approach than the creation of niche microformats like > hWine, though I'm open to argument in the other direction). > > This sounds very interesting... of course, there's a danger > here of going meta, and never coming back :) Yes, but I don't necessarily see that as a bad thing. As long as the microformat is helping people do what they need to do, I think it's all good and it could certainly keep the formal microformats at a bit higher level (while still allowing for extensibility). It could create a thriving subformat ecosystem, which I think is pretty neat. > As an aside, I find this use of automatically inferring > "property" and "value" inside a <DL> [1] problematic, because > it places a non-necessary burden on parsers, while making the > life of writers only minimally easier. > > [1] > http://microformats.org/wiki/hproduct-brainstorming#List_prope rty-value_association_.28groups.29 I'm not convinced of that. It is not all that difficult to parse a DL, in fact I just recently wrote a generic JS row-striping script that allows you to stripe tables and lists of all types (including DLs, even with multiple DTs or DDs per group, as per the spec) [1]. The code was only a few lines and could easily be repurposed to allow for harvesting of property-value pairs. It simply requires node walking as opposed to bulk collection. It's just an alternate sub-routine for collection based on the nodeName of the "p-v" CLASSified element. [1] http://easy-designs.net/code/stripey/test.php Also, I was reminded (by Tantek) that we need to be focused on writers more than parsers, and I think that from that standpoint, in the (edge) case where you need multiple values for a property/a single value for multiple properties/etc., DL makes a lot of sense -- much moreso than duplicating the p-v structure or embedding a UL inside the value. Consider it a DRY KISS [2,3]. [2] http://en.wikipedia.org/wiki/DRY [3] http://en.wikipedia.org/wiki/KISS_principle > Let's keep the topic of a general name/value subformat on the > table, and see how it develops. Agreed. I think this is really great stuff and could do a lot to allow for extensibility in microformats. Cheers, Aaron ---- Aaron Gustafson Easy! Designs, LLC http://www.easy-designs.net http://www.easy-reader.net _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
-- - Stephen Paul Weber, Amateur Writer <http://www.awriterz.org> MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 BLOG: http://singpolyma-tech.blogspot.com/ _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
