Re: profile attribute and conformance [was: Comparing conformance requirements against real-world docs]

Henri Sivonen wrote:

> It's interesting to see what preferences (i.e. unresolved arguments)
> the tool offers.

As author of said tool, I thought I'd weigh in.

> Only Strict eRDF is checked by default. "Strict Microformats" and
> "Strict GRDDL" mean that the tool forces itself to not recognize class
> and rel values if there's no profile URI. Since these are not checked
> by default, the developer of the tool has to have concluded that it's
> more useful for users of the tool to ignore the profile URI.

Don't read too much into that. Consider it an application of Postel's  
law - being liberal in what I accept from others.

The eRDF strictness option is on by default because applying eRDF  
parsing to pages which haven't been authored with eRDF in mind tends  
to generate junk. With the strict option enabled, it won't parse eRDF  
unless it sees the eRDF profile - i.e. the author has opted in.

> Also note that actually dereferencing profile URIs for GRDDL discovery
> is off by default because it is slow with two exclamation points.

For the majority of pages in the wild, Cognition does not need GRDDL.  
It has built-in support for hCard, hCalendar, XFN and a bunch of  
other microformats, including experimental support for a number of  
drafts from the microformats Wiki. If you enable GRDDL and your page  
provides GRDDL profiles for each microformat you use, then all the  
microformats on your page are parsed twice (the first time using  
reasonably fast built-in functions, and the second time using the  
slower GRDDL process) for no additional benefit. That's why it's off  
by default.

However, if you use a "microformat"[1] that Cognition doesn't have  
built-in support for - say you've invented your own "hWine" format  
for marking up your bottle collection - then providing a GRDDL  
profile, and enabling GRDDL when parsing will allow your data to be  
parsed, and thereafter used in the same ways that Cognition would be  
able to use it if it did have built-in support.

Overall, a method for pages to link to metadata profiles is needed by  
HTML. Whether it is head@profile or rel="profile" (or something else  
entirely) doesn't really matter as far as I'm concerned. That said,  
from what I can tell, the suggested change from head@profile to  
rel="profile" appears to be gratuitous "change for the sake of  
change". I don't see why HTML5 should break existing pages,  
specifications and tools that use head@profile.

____
1. I include this term in quotation marks because here I'm mostly  
referring to formats developed outside the microformats.org  
community, but labelled "microformats" by their creators. Every time  
one of these is labelled a "microformat", Tantek turns in his  
whatever it is that people turn in when they haven't died.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 5 September 2008 08:55:34 UTC