[whatwg] [WA1] The profile Attribute

Mon Apr 18 04:40:47 PDT 2005

Ian Hickson wrote:

>On Sun, 17 Apr 2005, James Graham wrote:
>  
>
>>>>>The only way I can see to avoid this is to use only one profile, 
>>>>>since then you can't ever get clashes.
>>>>>          
>>>>>
>>>>There are other ways I've seen proposed, such as using namespaces:
>>>>
>>>>http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm
>>>>        
>>>>
>>>Namespaces are not an option. Authors simply don't understand them.
>>>      
>>>
>>Respectfully, I think namespaces are the only sensible solution here and in
>>other situations where the document is mixing semantics from multiple sources.
>>    
>>
>
>The recent microformats trend (using profile="") is one other solution, 
>which seems to be at least as sensible.
>
>
>  
>
>>What's the evidence that authors don't understand namespaces?
>>    
>>
>
>One source for example is Micah Dubinko's statistic that 90% of all the 
>queries about XForms that he receives are asking for him to explain 
>namespaces. [1]
>
>  [1] http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html
>
>This certainly has also been my experience in dealing with Web authors who 
>are trying to use languages that rely on namespaces.
>
>
>  
>
>>Does it all come from XML namespaces (which are more complex than 
>>anything we would need for this type of problem*)? In any case I think 
>>this is a situation where, with sensible defaults, we can provide a 
>>useful feature that will be well within the grasp of the small subset of 
>>authors who actually want to use it.
>>    
>>
>
>By "namespaces" here I am refering to XML namespaces and similar solutions 
>that require declaring a prefix and then using that prefix elsewhere.
>
>
>  
>
>>For example we could define <profile name="foo" 
>>href="http://example.com/profiles/#foo" /> and then require a profile 
>>attribute for elements with rel values not assosiated with the default 
>>profile, which would be given by the value of the profile attribute in 
>><head> or the last <profile> element with no <name> value. That seems 
>>much simpler than XML namespaces.
>>    
>>
For clarity, that should read something more like:

For example we could define <profile title="foo" 
href="http://example.com/profiles/#foo" /> and then require a profile 
attribute for elements with rel values not assosiated with the default 
profile, which would be given by the value of the profile attribute in 
<head> or the last <profile> element with no title attribute e.g. a document like:

<head profile="http://example.com#foo">
<profile href="http://example.com#bar" title="bar" />
<link rel="comments" href="#comments" />
<link rel="license" href="license.html" profile="bar" />
</head>

would use the profile at http://example.com#foo for the first <link> and that at 
http://example.com#bar for the second.

>That seems a lot more complicated than the current proposed solution with 
>profile="".
>
Indeed. But, unless I'm missing something, the current spec totally 
fails to address the use-case of multiple profiles per document in any 
sort of useful way whatsoever. It seems entirely reasonable that people 
will want to include multiple profiles (since e.g. licensing and XFN 
type metadata is entirely orthogonal) so simply stating "authors are 
encouraged to avoid using multiple profiles" is, IMHO, a real problem.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs