[uf-new] Reusing classes names in multiple formats

[Brian Suda]

On 6/8/07, Scott Reynen <scott at makedatamakesense.com> wrote:
> This is the same problem with re-using any class name in multiple
> microformats.  As mentioned earlier, if we re-use "summary" in haudio
> (which I'm not arguing for nor against here), what if we want to
> embed haudio inside hreview?

SUMMARY is defined as:
A short summary or subject for the object.
http://microformats.org/wiki/classes

It is currently used in: vevent , hreview, hresume

> How do we keep the haudio summary from becoming the hreview summary?

--- this is true, but sometime you want it to be both! Microformats
are purposefully simple and MICRO, we are quickly getting to WHAT
IF... the original intent of microformats is NOT to boil the oceans
and have hundreds of formats! each time a few format is proposed it
does have to interact with all the others, and this is exponential
growth... some things will never be microformats, that is a fact of
life, we are MICRO by design.

There is now a nice sliding scale of technologies, from POSH, to
microformats, to RDFa to GRDDL all which do things slightly
differently with different output and results. Microformats do NOT
need to cater to every theoretical eventuality.

> More generally, I think we should be defining parsing rules based on
> the semantics, rather than vice versa.

--- this is difficult because the semantics are meant to be the same,
it is context that you want to look at, and sometimes you WANT it to
be in both contexts at the same time.

IF we start to propose that every term be prefixed with hcard-title so
it doesn't collide with media-title then we are no better off than
RDFa and namespacing. Microformats were designed with intent to avoid
this. In doing so we have set limitations on ourselves which we
readily acknowledge, we are NOT attempting to solve every problem, we
are after low hanging fruit, at some point we will have exhausted
those resources and things will no longer be 'easy'. We should avoid
constantly inventing new terms which mean the same thing, just so we
can avoid collisions - the only reason we would go down that road is
so that we CAN attempt to solve every problem and boil the oceans,
which is NOT one of the goals of microformats - that is solved by
other technologies NOT microformats.

firstly we should look at all the available properties[1] regardless
of where they are used. if we don't fine on that meets our needs, is
there existing formats or prior-art that is using properties,
otherwise we create new ones. If there are properties that already
exists, then we should do our best to use them. If we can't then we
should go back and look into creating new properties.

[1] - http://microformats.org/wiki/classes

-brian

-- 
brian suda
http://suda.co.uk