Re: Design Principles

Hi Leif,

First, let me clarify that I'm not arguing for or against the  
profile="" attribute. It would make little difference to me whether it  
is included, so I'm happy to let the people who feel they are  
stakeholders hash it out. I'm just trying to clarify how the design  
principles apply, as I see it.

On May 25, 2009, at 10:03 AM, Leif Halvard Silli wrote:

> Julian Reschke On 09-05-25 16.23:
>> Maciej Stachowiak wrote:
>>> ...
>>> If that's true, then probably the most applicable principle would  
>>> be "Support Existing Content."  But I don't think we have evidence  
>>> from the above that profile is in fact used a lot. Sounds like it  
>>> could be, depending on how much Dublin Core is used and whether  
>>> authors using DC follow the profile requirement.
>>> ...
>>
>> Why does it need to be used "a lot" for this design principle to  
>> apply?
>
> Indeed. This sounds a an example of the reversal  of the "pave the  
> cow paths" principle.

Even a very small amount of use, relatively speaking, counts as "a  
lot" on the Web. What I really mean here is used to a nontrivial  
extent and not just in artificial examples. The other important aspect  
of "support existing content" is whether any HTML consumer behavior is  
affected by the feature.

However, let me be clear. The fact that something *isn't* used a lot  
does not mean it should be automatically rejected. The design  
principles provide reasons to consider things for inclusion, but  
failing to meet some of those criteria does not amount to automatic  
rejection. Otherwise it would be impossible to add new features. As I  
understand it, this is also the point of view of Ian and many of the  
active group participants.

But if something isn't required solely for compatibility reasons, then  
the next step is to consider costs and benefits. My own opinion is to  
profile is that the benefits are quite low, but the costs are quite  
low as well. Which is why I'm personally indifferent as to adding it.

> Btw, I agree that "Support Existing Content" is applicable. But how  
> about such a thing as "Support Existing Specifications That Rely On  
> Extension Features of HTML 4 and XHTML 1"?

I don't think that's generally been applied as a design principle. You  
could argue that it's a good rule, but the Design Principles document  
was intended largely to explain the thinking that had gone into the  
design. In fact, you could say that one of the motivating forces of  
HTML5 is to explicitly reject this principle, and not assume that what  
previous specs say must necessarily be respected.

>  The other unspecified principle, the "From Scratch" principle,  
> really hasn't been followed through [or perhaps that is exactly what  
> has happened?] so long as HTML 5 fails to cater for those  
> specifications.  (Ore we could say that, here, again, we see an  
> example of the browser focus of the draft.)

I don't think "From Scratch" is a principle either. There's really two  
ways in which this comes up: (1) As it happens the spec was written  
starting with an empty buffer instead of starting with the text of  
HTML 4.01; this isn't really relevant to the design of the language  
though. (2) Features present in HTML 4.01 were not automatically  
included. This mostly comes up when arguing whether something was  
"removed" or "not added", which doesn't seem like an important point  
to me. The important consideration in such cases is whether it is  
needed (both in the sense of client support for the construct, and in  
the sense of allowing it to be considered conforming).

> It would eventually be up to the /Dublin Core Metadata Initiative/  
> to pave their own cow paths, as it is their specification. However,  
> it seems as if they, since 2008 [but already starting in 2003], put  
> more weight on using @profile, so it looks as their attempt to  
> 'cowpath' the 'DC' prefix was found to be the wrong path.  I think  
> they do the right thing when they avoid authorizing anything without  
> using the extension mechanism that HTML has. If the goal is that  
> anyone using "text/html" today should upgrade to "HTML 5 - text/ 
> html" when the spec is ready, then it seems productive to this HTML  
> 4/XHTML 1 feature and instead improve it.

That's a decent argument for profile. I don't think it is a cowpaths- 
style argument, though, since that depends on what authors do, not  
what specs say they should do.

Regards,
Maciej

Received on Tuesday, 26 May 2009 02:52:41 UTC