[uf-discuss] Custom Fields Microformat?

[Stephen Paul Weber]

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 <aaron at easy-designs.net> 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
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


-- 
- Stephen Paul Weber, Amateur Writer
<http://www.awriterz.org>

MSN/GTalk/Jabber: singpolyma at gmail.com
ICQ/AIM: 103332966
BLOG: http://singpolyma-tech.blogspot.com/