Tantek Celik [EMAIL PROTECTED] wrote: > On 11/26/06 10:49 AM, "Aaron Gustafson" > <[EMAIL PROTECTED]> wrote: > >> Tantek Celik [EMAIL PROTECTED] 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
