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

On 7 Sep 2008, at 14:20, Henri Sivonen wrote:

>  * A prominent (the most prominent?) microformat-to-RDF converter  
> ignores profile for microformats and rel=transform by default, so  
> authors can have their stuff consumed even without the profile.

Just because the profile is not required, it does not mean that it is  
ignored. e.g. for parsing XFN <http://gmpg.org/xfn/>, the profile (if  
supplied) is may be used to determine which version of XFN (1.0 or  
1.1) is in use. XFN 1.1 defines a handful of additional terms over  
XFN 1.0 including rel=contact, which was (until recently) in conflict  
with the definition of rel=contact in HTML5 - so there was (until  
recently) a very important reason to differentiate between XFN 1.0  
and XFN 1.1.

Conflicts in naming schemes pop up all the time (look at Twitter's  
hCards). Profiles offer a means to disambiguate.

> Given that you are doing what you are doing (regardless of *why*  
> you are doing it), what incentive is there for authors to use  
> profile? What do they gain if they use it? What incentive is there  
> for the users of your software to change the default settings?

What incentive is there for authors to validate against HTML 4.01  
Strict instead of HTML 4.01 Transitional? A warm fuzzy feeling  
certainly, but it's more than that. While Cognition gets robustness  
from following the second part of Postel's Law ("be liberal in what  
you accept from others"), authors get their robustness from following  
the first part ("be conservative in what you do").

> Have you analyzed your logs to see if your users do change the  
> defaults often?

Just over 20% seem to. I've not checked which defaults are changed  
most often.

>> Overall, a method for pages to link to metadata profiles is needed  
>> by HTML.
>
> How does this follow?

Follow from what you quoted? It doesn't. From what you quoted, a  
profile mechanism is potentially useful, but far from necessary. It  
follows from what you snipped:

> 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.


Basically, if you create your own "microformat"[1], thanks to  
profiles and GRDDL, you don't need to beg and plead parser  
programmers to implement support for it - any GRDDL parser (of which  
Cognition is one) will automatically start picking it up.

Are there alternative ways HTML5 could implement profiles other than  
<head profile>? Yes, of course. But does it make sense to replace one  
profile mechanism, with dozens of implementations and used by  
millions of pages, with a different one (rel="profile")? Perhaps, but  
I'm not convinced by the arguments I've seen so far.

Replacing <head profile> with rel="profile" is feasible in the same  
sense that replacing <style> with <script type="text/css"> would be  
feasible. Fairly easy changes to make as far as implementations are  
concerned, yet utterly pointless. Why change an existing mechanism  
unless there are real benefits to be had?

____
1. Footnote in http://www.w3.org/mid/DFE64301-A333-43A0-82E9- 
CB7A1C06C64D@g5n.co.uk

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

Received on Monday, 8 September 2008 08:21:14 UTC