[uf-discuss] Custom Fields Microformat?

[Aaron Gustafson]

Tantek Celik [tantek at cs.stanford.edu] wrote:
> On 11/26/06 10:49 AM, "Aaron Gustafson"
> <aaron at easy-designs.net> wrote:
> 
>> Tantek Celik [tantek at cs.stanford.edu] wrote:
>>> Aaron,
>>> 
>>> DL/DT/DD in XHTML can already be used to semantically represent
>>> property value sets and XOXO uses them for this purposes. Hence XOXO
>>> already solves this problem by reusing semantic XHTML.
>>> 
>>> Tantek
>> 
>> I understand that, so should a DT-based XOXO within any microformat
>> (hCard, hCal, hProduct, etc.) automatically be considered properties
>> for that card/caledar/product? How would it work with a list of
>> properties and values or natural language properties and values? It
>> seems like some part of the XOXO spec should specify how to handle
>> that (I couldn't find any mention of it, perhaps you could point me
>> to the right place...?) or the scope of XOXO should be
> expanded to allow for situations like these.
> 
> Quite the opposite actually.
> 
> The goals of any format are data fidelity and
> interoperability over time and space, to which microformats
> adds a few more principles, like ease of use for humans first
> rather than machines (though even that is derived from
> observing that formats easier for humans lead to better data
> fidelity). 
> 
> Arbitrary extension of the properties/values of any
> microformat just leads to significantly worse
> interoperability as people mutate it in numerous directions -
> e.g. babel.  The only partial exception to that we have found
> that appears to work in the wild is "tagging" - where there
> is an upfront expectation of a semi-chaotic (but also
> emergent semi-orderly) folksonomy.
> Yet folksonomies themselves make poor data formats, for the
> same reason.
> 
> Thus arbitrary extensibility is actually a design-antipattern
> for those goals, and to be explicitly avoided when designing formats.
> 
> Since XOXO itself only defines nested lists (and sets) of
> items with arbitrary properties/values (with a certain fixed
> known set for compat with existing uses), there is no
> expectation that user/author defined properties themselves
> will interoperate.  In that extent XOXO is a more like a
> meta-format like XML, RDF, or JSON that itself can be used to
> define data-type specific formats, rather than like hCard and
> hCalendar that are used to represent and interchange specific
> types of data.

I guess I uunderstand how the extension of something like hCard or hCal over
time should be constrained to adjustments within the spec (hence the version
property), but I guess I would still support the use of some property-value
construct within a potential microformat such as hProduct.

To me, the creation of niche microformats (lets say some hypothetical
examples are hBook, hVideoGame, and hTelevision) seems somewhat wasteful as
there are obviously a set of properties which they would share (name,
brand/publisher, retail price, etc.). In the interest of respecting the DRY
principle (and not reinventing the wheel each time), wouldn't it make more
sense to create a generic format (hProduct) to contain that standard data
and then allow for the standardization of subformats based on that format to
be generated?

For instance, if someone wanted a subformat for books, there would be a
certain standardized property-value list (much like the microformat
properties we use now) for things like author, co-author, ISBN, etc.
Similarly, for video games you could have UPC, ESRB rating, etc. All of the
appropriate properties could be codified (and evolve) in the standard
microformats way on the wiki to keep it from being disorganized chaos. In
other words, the properties would (like many microformats) not be required,
but they would not be arbitrary either.

I guess I see property-value extensibility -- particularly within a
potential microformat such as hProduct -- to be beneficial, helping both the
people who are publishing the content and people who are collecting that
content for whatever purpose do so as easily as possible. For more
information on possible uses of this see the hProduct brainstorming [1].

[1] http://microformats.org/wiki/hproduct-brainstorming

Note: I am not against using XOXO for the proprty-value stuff, just trying
to wrap my head around how XOXO would solve the problem. Obvioulsy it makes
sense in using DL and (possibly) UL/OL, but natural language properties are
a little outside its scope yet could still be structured. I could see there
being some hybridization of XOXO and the p-v construct which allows for
simplification of authoring (i.e. if using p-v on a DL, no property/value
classes are necessary -- which we already suggested -- by making the DL have
a class="p-v xoxo" or some such).

Cheers,

Aaron

----
Aaron Gustafson
Easy! Designs, LLC
http://www.easy-designs.net
http://www.easy-reader.net