[uf-discuss] Custom Fields Microformat?

[Aaron Gustafson]

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