[uf-discuss] PROPOSAL: keep it simple; make it extensible?

David Janes davidjanes at blogmatrix.com
Sat Nov 18 13:54:50 PST 2006


My current plan is (and has been) to keep it as simple as possible and
_not_ to try to solve the "everything" problem. In particular, my
current thinking is here [1] which basically says do the same thing
with "item" from hReview/hListing as was done to "adr" and "geo" from
hCard, add a missing field or two ("description" in particular) and
then expect that future microformats (hWine) will composite on top of
that.

The property-name/property-value thing I think is totally out of scope
for _I_ want to do! I understand the potential value of that and it's
probably worth an entirely exporatory series of wikipage of it's own
(and there's lots of examples that can be drawn upon from out on the
net, plus the work that's been done on microformats-rest). If you
think it's worth tackling, I'll certainly contribute examples from
what I've seen on the net.

I think that you've inverted the parent-child relationship between
(say) a review and a item; that is, it is more natural to expect the
item to be a child/attribute of the review rather than the other way
around.

Regards, etc...
David

[1] http://microformats.org/wiki/item-brainstorming#DavidJanes

On 11/18/06, Andy Mabbett <andy at pigsonthewing.org.uk> wrote:
>
> Rather than trying to devise a microformat (hThing or hItem) that can
> describe any thing (or at least any physical thing), with all the
> possible or probable properties that might entail: would it perhaps be
> better to define a re-usable wrapper, and say that any microformat(s) or
> properties inside that wrapper apply to that thing?
>
> Say:
>
>         <span class="hitem">
>                 [hReview]
>                 [other uFs]
>         </span>
>
> Then apply secondary classes to the hItem as microformats are developed
> in future, say:
>
>         <span class="hitem wine">
>                 [hReview]
>                 [other uFs]
>         </span>
>
>
> We could then use:
>
>         <span class="hitem">
>
>                 <span class="[property-name]">
>                         <span class="value">[n]</span>
>                 </span>
>
>         </span>
>
> or
>
>         <span class="hitem">
>                 <span class="property">
>                         <span class="type">[property-type]</span>
>                         <span class="value">[n]</span>
>                 </span>
>         </span>
>
> for various properties or property-types ("abv", say) as and when
> they're required:
>
>         <span class="hitem wine">
>
>                 [hReview]
>
>                 <span class="abv">
>                         <span class="value">7.8</span>
>                 </span>
>
>         </span>
>
> or
>
>         <span class="hitem wine">
>
>                 [hReview]
>
>                 <span class="property">
>                         <span class="type">abv</span>
>                         <span class="value">7.8</span>
>                 </span>
>
>         </span>
>
>
> Or, where no "secondary class" exists, parsers would simply infer that
> the properties apply to the item:
>
>         <span class="hitem">
>
>                 [hReview]
>
>                 <span class="property">
>                         <span class="type">abv</span>
>                         <span class="value">7.8</span>
>                 </span>
>
>         </span>
>
> or could extract the nature of the item from a tag:
>
>         <span class="hitem">
>
>                 <a rel="tag" class="hitem-type"
>                 href="http://www.example.com/wine>Wine</a> News
>
>                 [hReview]
>
>                 <span class="property">
>                         <span class="type">abv</span>
>                         <span class="value">7.8</span>
>                 </span>
>
>         </span>
>
> or class:
>
>         <span class="hitem">
>
>                 <span class="hitem-type">Wine</span> News
>
>                 [hReview]
>
>                 <span class="property">
>                         <span class="type">abv</span>
>                         <span class="value">7.8</span>
>                 </span>
>
>         </span>
>
>
> Such properties could then be proposed and agreed more speedily then
> entire uFs.
>
>
> Items could be nested, with any properties in the inner item applying to
> that, and not the outer item(s).
>
>
> Alternative names could be "hThing" or "hObject".
>
>
> This post contains several "blue sky" proposals, which can be considered
> separately, if not as a whole.
>
>
> (Note: "wine" and "abv" are used for illustration only, and not to imply
> any endorsement or otherwise to the current "wine" proposal)
>
> --
> Andy Mabbett
>                 Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>
>
>                 Free Our Data:  <http://www.freeourdata.org.uk>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onamine.com
http://blogmatrix.blogmatrix.com


More information about the microformats-discuss mailing list