Re: Design Principles

Maciej Stachowiak On 09-05-25 16.15:
>
> On May 25, 2009, at 6:15 AM, Leif Halvard Silli wrote:
>
>> Maciej Stachowiak On 09-05-25 14.41:
>>>
>>> On May 25, 2009, at 5:29 AM, Leif Halvard Silli wrote:
>> It is not fair only time the design principles are applied is when 
>> someone is /citing/ them. This WG has many times been presented with 
>> statistics that lists how many times something is used. Where do we 
>> see in the principles that this is the right thing to do? When 
>> something has been found/claimed to not be much (correctly) used, 
>> then it has been used as a argument for "removing" (putting it in 
>> quotes to satisfy Anne) the attribute. I see this as an example of 
>> what you ask.
>
> I would say that, first off, if people are doing such things without 
> citing the principle, then removing or changing the principle will not 
> affect their behavior. But if they do cite it, it can be pointed out 
> that they are applying it wrong.
>
> My own impression is that quantitative studies are used to answer 
> questions like these:
>
> - Would removing support for a particular tag or attribute 
> significantly hurt compatibility with existing Web content? (Support 
> Existing Content)
> - Would altering the parsing or interpretation of a certain tag or 
> attribute significantly hurt compatibility with existing Web content? 
> (Support Existing Content)
> - What values of freeform semantic attributes may be de-facto 
> standards? (Pave the Cowpaths)
> - Are certain attributes or elements used wrong more often than they 
> are used right? (not clear if this relates directly to a stated design 
> principle)
>
> The answers to these kinds of questions cannot by themselves lead to a 
> conclusion that some markup feature should be left out. But they can 
> help inform the decision.
>
> I hope this clarifies the "Pave the Cowpaths" principle and how it 
> relates to quantitative studies of Web content.

The principle says that one should /consider/ paving cowpaths instead of 
inventing new things. We must then consider what /is/ the @profile 
feature? What does it represent? Do you have any clear answer to that?

I'd say that the invention of "microdata" is something that eats into 
the profile concept.  The introduction to "RDFa for HTML Authors" [1] 
explains how RDFa "extends the possibilities of metadata in XHTML, by 
generalising the attributes on meta and link and allowing them to be 
used on any element, not just meta and link"[1]. It would have been 
logical to follow similar extend and generalise path in HTML 5 as well 
so that the profiles concept was extended to also govern the global 
@content attribute, for instance. But instead of following an extension 
path, it seems like  "microdata" has been designed so that DC cannot be 
extended to also be used in the microdata attributes. I don't know if 
they would like to do that, as the title of the DC-HTML profile is 
"Expressing Dublin Core metadata using HTML/XHTML _meta and link_ 
elements" [2], but it seems to me that it would have been natural if the 
profile concept was extended to all the new metadata attributes.

We can also discuss what /is/ a "cowpath"? Is it _not_ a cowpath if its 
use is based on a specification? And especially not if it is based on a 
W3 specification? (Hint: RDFa versus "microdata".)

[1] http://www.w3.org/MarkUp/2009/rdfa-for-html-authors#Extending
[2] http://dublincore.org/documents/2008/08/04/dc-html/
-- 
leif halvard silli

Received on Monday, 25 May 2009 17:29:50 UTC