Tantek Celik [tantek cs.stanford.edu] wrote:
> On 11/26/06 10:49 AM, "Aaron Gustafson"
> <aaroneasy-designs.net> wrote:
>
>> Tantek Celik [tantekcs.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] h
ttp://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.n
et
http://www.easy-reader.net
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|