[microformats-discuss] URIs please!
bud at thecommunityengine.com
Thu Jul 14 05:28:34 PDT 2005
On Jul 14, 2005, at 6:14, Danny Ayers wrote:
> Sure, there's an advantage in having well-known semantic markup terms,
> the vocabularies defined in microformats. But for automatic discovery
> and processing it's also hugely beneficial to be able to recognise
> microformat data unambiguously. The doc can be processed in a way
> appropriate for the microformat. The profile URI provides this
> disambiguation and allows deterministic processing. This doesn't in
> any way compromise the "simplicity" aim of microformats, in fact the
> net effect is overall simplification. Hunting for arbitrary strings in
> attributes is hard work!
I could not agree more with the issue you raise and was just thinking
on this issue as I went to sleep last night and woke this morning. I
included this issue in the XMDP brainstorming on this wiki page:
The person who joined me as page author is not in agreement with us
and has marked this issue as REJECTED, with a signed objection on the
page from me. In my objection I use almost this exact example for
why it should not be rejected:
> Now you are likely to get a lot more docs which don't contain
> microformat data than those which do. Ok, so "xfolkentry" is unlikely
> to be misinterpreted. But what if the documents contain e.g.
> <div class="name">
> Is this microformat data? Which microformat?
I believe an equivalent solution to what you suggest is, within the
XMDP, to designate an element unambiguously as the container element
(all microformats seem to have one). Automated parsers could pick
that attribute value up and parse for it as an indicator that
microformat is in use. This solution is really just the automation of
the "by-hand" method you employed. Admittedly, the solution does not
have the force of a URI, but with most microformat container names,
the difference from a URI is academic and more human friendly.
Right now, since not everyone uses the XMDP, people developing
parsers for microformats have to create a hand generated list of
container class elements to parse for. That's still workable at the
current scale of things.
Thanks for the observations. I think they are well made.
More information about the microformats-discuss