Custom Fields Microformat?

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 <aaroneasy-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-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
>


-- 
- Stephen Paul Weber, Amateur Writer
<http://www.awriterz.org&g
t;

MSN/GTalk/Jabber: singpolymagmail.com
ICQ/AIM: 103332966
BLOG: http://singpolym
a-tech.blogspot.com/
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Stephen Paul Weber wrote:
> 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

I'm not sure I understand what you're getting at with XOXO.

I have re-read the specs based on your comment, looking for
a connection, but maybe I'm missing something. Can you
explain why you think a property-value grouping microformat
would overlap with XOXO? It's not really an outline? I
realize some instances make use of a list-based construct,
but it could be natural language as well. Furthermore, it
seems to me that your argument would nix any microformat
that utilizes an (X)HTML list construct, which I think is
extreme. And if someone thinks a property-value list is an
appropriate XOXO, there's no reason they couldn't combine
the two. I just see property-value filling a particular gap
in terms of microformat extensibility, particularly for
something like hProduct.

IMHO property-value doesn't appear to overlap 80%, or even
30%, with XOXO. Perhaps you could explain your resoning in a
bit more detail?

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