Custom Fields Microformat?

On 11/25/06, Aaron Gustafson <aaroneasy-designs.net> wrote:
> Manuel Simoni wrote:
> > the hcustomfield-* classes are minimally
> > invasive:
> >
> > <ul>
> >  <li class="hcustomfield">
> >   <span
class="hcustomfield-name">Priority</span>
:
> >   <span
class="hcustomfield-value">low</span>
> >  </li>
> > </ul>
...
> This is very similar to the property-value pair/group
concept[1] we have
> floated as part of hProduct.
>
> [1] http://microformats.org/wiki/hproduct-brainstor
ming#Extensibility

Cool, I think it's isomorphous... The "p-v"
corresponds to
"hcustomfield", the "property" to
"hcustomfield-name" and the "value"
to "hcustomfield-value".

> 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  However,
like for custom fields
in weblogs and CMS, I can imagine that such a subformat
could make use
of primitive values (strings at least) and links to other
resources.

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://microform
ats.org/wiki/hproduct-brainstorming#List_property-value_asso
ciation_.28groups.29

Let's keep the topic of a general name/value subformat on
the table,
and see how it develops.

Cheers,
Manuel
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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-brainstormin
g#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.n
et
http://www.easy-reader.net
 

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss