Re: Design Principles

Anne van Kesteren On 09-05-25 19.59:
> On Mon, 25 May 2009 19:48:05 +0200, Leif Halvard Silli 
> <lhs@malform.no> wrote:
>> Because, as I said, it is isn't useful to convince me about anything 
>> that you tell me that you have looked at it from scratch. The "from 
>> scratch" principle would in itself need to be defined, btw.
>
> I don't really see how it's a principle and I'm not sure why you need 
> to be convinced about it.

I thought that you used it because you thought it was a convincing 
argument to use. It has certainly happened many times that the "from 
scratch" argument has been used as a justification. That to me makes it 
a de-facto design principle (for some) that fails to be in the Design 
Principles. Although some may feel that it is included in "Don't break 
the Web", which some perhaps think is a principle - although it isn't in 
the Principles.

Here is a look at @profile vis-a-vis the principles:

    * 2. Compatibility
2.1. Support Existing Content 
     = support @profile

2.2. Degrade Gracefully       
     = no degradation issues

2.3. Do not Reinvent the Wheel
     = support and extend the profile concept (+ RDFa) instead of 
inventing new "microdata"

2.4. Pave the Cowpaths
     = this to me also supports building on existing profile related 
authoring practises such as microformats. Or is it only those 
microformatters that do /not/ use @profile that represent a cowpath?

2.5. Evolution Not Revolution
     = do not cut off @profile or the profile concept

    * 3. Utility
3.1. Solve Real Problems
     = find a solution to @profile.

3.2. Priority of Constituencies
     = @profile might be "theoretical purity". But does it help anyone 
to drop it therefore? Why and how? Who are "users" w.r.t. meta data?

3.3. Secure By Design
     = it should be secure

3.4. Separation of Concerns
     = it separates out the meta data concern

3.5. DOM Consistency
     = my pet: @rel="schema.*" more DOM consistent than @xmlns. I 
/think/ that even rel="xmlns:CURIE" should be. @rel="schema.*" is not 
@profile but it is related to the concept.

    * 4. Interoperability
4.1. Well-defined Behavior
     = The thing with @profile is that it defines something that it is 
up to /other/ constituencies than this working group to define. The well 
defined behaviour of a profile is the task for the profile definers.

4.2. Avoid Needless Complexity
     = It is not up to use to tell others that @profile is too complex. 
Though we can of course try to define something better or simpler.

4.3. Handle Errors             /?
    * 5. Universal Access
5.1. Media Independence        /?
5.2. Support World Languages   /?
5.3. Accessibility             /?

>
>>> There's some disagreement over a few HTML4 features. By and large I 
>>> think the group is in agreement over the other features. I haven't 
>>> seen anything to the contrary anyway.
>>
>> Whether one can use @xmlns might be described as "one of few 
>> features", of course ...
>
> xmlns is not an HTML4 feature.

Of course. For a moment I had the XHTML 1.0 roots in mind as well. Sorry.


>>> The design principles do not really appear to help in these 
>>> discussions, but I think in the latest iterations they have not 
>>> really been used as verbatim either so they're not a huge problem 
>>> either.
>>
>> I think the design principles should help us make decisions. If they 
>> don't they have failed.
>
> The goal was mostly to explain the design rationale to date. They're 
> certainly not meant as rigid rules.

But they should be of help.  There must be some rigour about what they 
mean. Or else it simply become feelings.  E.g.  you said that you did 
not see that Principles had been broken. But I really wonder how one can 
say anything like that about the "Pave the Cowpaths" principle. Do we 
keep a list of the cowpaths? Have we dealt with them all now? How many 
are left?

>>> It certainly requires you to do something (figuring out what authors 
>>> do), but that seems a vastly different thing from how the 
>>> specification is being edited.
>>
>> It seems a bit pointless to discuss principles if it is only up to 
>> one person to follow them, IMHO.
>
> I'm not sure what you're saying here.

I am sorry, but I am only a HTML 4 kind of man who can never reach the 
HTML 5 level of precision in my speak. But I can try again: It is pretty 
strange to be very "law abiding" on the principle of having Design 
Principles but just overlook other normal W3 expectations and principles 
about how an editor should work.

I would, in fact, loved to have good design principle that was useful 
and mostly agreed upon. But then there is a need of "meeting of minds" 
as Laura said. And I think it is hard to find meeting of minds when we 
cannot even agree on what the word "removed" refers to.

>> And if the failing to agree on principles represents a danger by 
>> setting a precedence that we are unable to agree about anything, then 
>> the same can be said about how the editor operates.
>
> I still don't see how that makes them principles.

You are right. But it is difficult to take the Design Principles any 
more seriously than other principles that should be the foundation of 
our work.

> And yeah, getting a large enough group to agree on anything is hard. 
> Fortunately the decision policy this WG is using takes that into account.
-- 
leif halvard silli

Received on Tuesday, 26 May 2009 01:50:12 UTC