> Mike Schinkel wrote:
>
> Ryan Cannon wrote:
> > If the community is slow to develop a format that
makes
> > sense, we often encourage authors to develop their
own
> > systems, which then can inform how a format will
function in
> > the wild. This is where documentation and the
oft-belabored
> > "process" becomes powerful. Although it
can be annoying for
> > early-adopters and people who need solutions now,
it creates
> > strong formats once the issues are solidified.
>
> Arrgghhh! (he says, frustrated that people address the
> tangent to his issue, but don't/won't address his
actual issue!)
>
> So I repeat: How then can we achieve a disambiguation
> conventions to keep official Microformats from
conflicting
> with "proto- Microformats?"
Mike,
Microformats has no mechanism in place to disambiguate,
either amongst
its own uFs or between its own and other
"non-official" microformats.
Tantek wrote:
> A "microformat" is such because it is a use
of semantic class
> names, etc. that IN PARTICULAR:
>
> 1. Are designed according to microformat principles [1]
>
> 2. Follow the microformats process [2]
>
> [1]
> http://microformats.org/wiki/microformats#t
he_microformats_principles
>
> [2] http://microform
ats.org/wiki/process
Although the process says to use the microformats wiki and
mailing list,
there is no "official" blessing as both of these
media are either
unmoderated or "community" moderated. Any user
could make
recommendations and edits. A team of antagonistic users
could hijack it
completely. There really is never an "official"
version of any given
microformat, although there have been statements that
eventually their
will be when shepharded through a standards body. The only
real
authority is the autocratic role played by Ryan and Tantek.
For example, since it was initially stabilized hCard has
been changed to
include "place" in its semantics, yet we have no
way to let parsers know
that the "new" hCards may not be people,
companies, or organizations,
but instead may also be places. vCards were for
/contactable/ entities.
hCards changed the semantics to include
"locatable" things because the
address capability of existing hCards made that convenient.
Yet, there
is no versioning to disambiguate between these two. That
means that
once a standards body blesses any particular microformat, it
will be
locked in stone. I for one think hPlace (or something)
should be a
separate uF, based on the location-related fields in hCard.
Similarly, there is no mechanism to distinguish class names
in one hcard
from names in another, so we are forced to make sure that
the entire
namespace is flat and hopefully unique enough from random
semantic HTML
in the wild.
If it looks like a duck and quacks like a duck, you really
can't tell if
it is a duck, but the parsers will try to treat it like a
duck anyhow,
even when it is simply semantic HTML that happens to have
the same class
names as a microformat.
The initial concept, as I understand it, was that divergent,
namespace-enabled variants are bad. That instead, a
community-forged
single namespace based on consensus is better. I agree with
the intent
of the latter. It is good to have a shared tongue. However,
I think
that goal is compatible with the existence of namespaces (or
other
disambiguation). Just as having an international language
of commerce
and science is good (English serves this purpose today), it
is also
entirely compatible with a world where people are allowed to
speak other
languages, especially when knowing which language they are
using helps
you clarify their meaning.
I, for one, think we need a mechanism to disambiguate, but I
didn't have
much success with my early arguments. Apparently I hit a lot
of
hot-buttons and got shouted down (some of my suggestions
were somewhat
tangential to this particular point and probably deserved
getting
shouted down). The idea of disambiguatable namespaces stirs
up
exhortations against a "Babel"-like profusion of
uFs, which apparently
would be the end of the world and somehow inherently prevent
the forging
of the consensus uF namespace. I don't buy that argument,
but it is the
one that has held sway here since the creation of
microformats.
That's ok. Microformats are still cool. I just don't think
they scale
well, which is apparently by design.
-j
--
Joe Andrieu
joe andrieu.net
+1 (805) 705-8651
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
