[uf-discuss] Microformat tools bogosity test
Danny Ayers
danny.ayers at gmail.com
Wed Mar 7 08:57:33 PST 2007
On 07/03/07, Scott Reynen <scott at randomchaos.com> wrote:
> On Mar 7, 2007, at 3:51 AM, Danny Ayers wrote:
>
> >> We seem to be at the "iterate" stage now with the ambiguity problem,
> >
> > There I disagree - as far as the theory goes, for microformats the
> > problem is effectively solved.
>
> I'd say the problem isn't solved until the solution is actually
> adopted, and one way to increase interest in adoption is to more
> clearly demonstrate the problem we're solving.
Ok.
> > The notion of profile URIs has gone through the community process, and
> > there's even a microformat to support them: XMDP. It's been accepted
> > that each microformat should have a profile URI [1].
>
> If it's gone through the process, where are the examples? It would
> be a lot harder for people to claim it's not really a problem if they
> could see some examples of the problem. I assume that's what you
> were trying to do with your soup dragon, but such contrived examples
> are not very compelling.
The soup dragon is a test case, by definition it's contrived. Whether
or not it's compelling depends on how you view test cases. Say there
was a particular piece of HTML which would crash a browser. Either the
problem could be isolated in a test case, submitted to the bug
database and hopefully soon fixed. Or it could be ignored, and
dismissed on the grounds that it's unlikely to happen in the wild. Ok,
failure to pass the test in this case is less dramatic than software
crashing, but misinterpretation of data is still undesirable. It's
still a bug.
> > Just to reiterate the rationale for profile URIs : if publishers
> > include one, they have made a clear assertion according to the
> > conventions of web architecture and the relevant specs that they're
> > using that microformat.
>
> I think I understand the rationale for profile URIs. What I don't
> see are examples demonstrating that rationale.
There are now around 10 independent implementations [1] of the GRDDL
mechanism (the spec of which just went to W3C Last Call [2]) which
can be used with microformat data. The mechanism relies on there being
a profile URI.
It seems likely that in practice many applications working with
documents in the wild will use GRDDL loosely - e.g. running tag soup
HTML through HTML Tidy, using regexps to infer uF usage. But right now
anyone wishing to create GRDDL-friendly HTML is likely to opt for eRDF
or RDFa or a custom dialect rather than microformats, as most
microformats are underspecified, lacking profile URIs.
I similarly
> understand the rationale for valid HTML, but I don't expect many to
> actually care about that until it becomes a problem they can easily see.
>
> > But it's ludicrous that the
> > webarch-friendly option isn't currently available.
>
> And it's ludicrous that people still publish tag soup HTML too.
But people can publish valid HTML if they want to, they have a choice.
Until profile URIs are available for the microformats, people don't
have the choice (unless they create their own profile URI). In effect,
publishers and consumers wishing to follow best practices in
publishing embedded data in HTML are penalised.
So
> how can we change this situation? I think we've established after
> several rounds on this topic that saying "we need profiles" doesn't
> change much. In the interest of progress, let's try something
> different this time. Document some examples, write some more XMDPs,
> anything other than repeating the same discussion we've had several
> times already. Because that clearly does not work.
I've written XMDP profiles, I've created a test case. It doesn't seem to work.
It would be better if profile URIs were created with the blessing of
microformats.org, but if they're unwilling to take the minimal action
necessary, it seems inevitable that people that need them will create
them without that blessing.
Cheers,
Danny.
[1] http://esw.w3.org/topic/GrddlImplementations
[2] http://www.w3.org/TR/grddl/
--
http://dannyayers.com
More information about the microformats-discuss
mailing list