Re: Design Principles

Jonas Sicking On 09-05-30 21.25:

>>        So the cowpath principle is *feature focused*. That is why I am
>> focusing on what kind of feature @profile represent. I expect, if you want
>> to link the cowpaths principle to @profile, that you have a clear
>> understanding of what feature @profile is, and that you have considered
>> using @profile for it.
> 
> Indeed. I fully agree. I do not want to link the cowpath principle to @profile.
> 
> So I guess we agreed all along :)

>> As example of what you are asking: I do feel that the /way/ you above have
>> applied the cowpaths principle to @profile represent a misapplication. See
>> above about why.
> 
> I did not mean to apply the cowpath principle to @profile.
> 
> In fact, I question that there is enough usage of @profile out there
> for @profile to constitute a cowpath. But I don't have any data either
> way on this.

I'm sorry, but why do you talk about "not enough usage to be a 
cowpath" if you do not mean to refer to the principle? Since you 
insist on this point:

My view is that if we ask if @profile is a cowpath, then yes it is 
a cowpath, if we consider profile specifications. (From another 
perspective, however: there are also examples of the opposite, 
e.g. when Google expands HTML with their own @rel values. Even 
though profile pages that standardise what Google has decided also 
exist [1])

When it comes to authors that use profiles - aka microformats - 
then, yes, there seems to be less of a cowpath story.

@profile also is a policy thing. It is about ownership and control 
over HTML.

>> We could have had a principle that said "Go critically through all the
>> features of HTML 4 and see if there is much dead meat". But we do not have
>> this. (And I suppose that one of the reason we do not have it is because
>> such a principle would have defeated the "from scratch" principle.)
> 
> I agree, we don't have such a principle. But it does seem like a good
> idea to any time you write a spec, go through all the features of that
> spec and make sure that it still makes sense to keep them in the spec.
> No matter if the reason they were in the spec in the first place is
> because they came from a previous version of the spec or because it's
> a newly added feature.
> 
> Having "dead meat" in the spec seems like a bad idea, no matter what.
> Wouldn't you say?
> 
> I don't think the design principles are the only rules that guide us.
> We also follow the rules of our charter, the rules of W3C, and rules
> of common sense, and probably other rules as well.


As for "other rules than the principles", it seems to me that 
interoperability with HTML 4 (!) and the XHTML family binds us to 
have it. (Indeed, Ian has already tried to get other specs to 
change, in order to have support for removing @profile. [1])

"Dead meat" was a word I used about those things that we have 
inherited from HTML 4. That we of course should have no dead meat 
at all in HTML 5, is another issue.


>>>>> *If* @profile hasn't solved any real world problems in
>>>>> the decade that it has been deployed, I would think that we can claim
>>>>> that it doesn't fulfill that design principle.
>>>> This is not true. Profile solve a real world problem: Link to/inform
>>>> about
>>>> the profile you are using. The only other method that I know about is
>>>> relying on heuristics and code investigation.
>>> Since this is a already deployed specified feature (HTML4 defiend
>>> @profile about a decade ago), so we should actually be able to examine
>>> if it indeed solves a real world problem, and if it does it
>>> effectively.
>> "... if it indeed solves a real world problem ... " You are a bit vague
>> here. I am sure you can tell me whether @profile solves the problem of
>> linking to a profile very easily.
> 
> But is needing to link to a profile a real world problem. And does
> @profile indeed solve it well?
> 
> *If* @profile has seen very little usage in the many years it has been
> deployed, and again, I don't have good data either way on this, then I
> would think one of the following would apply:
> 
> The problem it aims to solve isn't a problem that very many people need solved
> - or -
> It for one reason or another isn't solving the problem well
> 
> Though maybe there is some other reason that I can't think of right now?

Regarding "needing". How do we decide "need"?

- Yes, we need it for interoperability with HTML 4 and XHTML and 
other W3 spec.
- as subsequent arguments:
   - it is abut the exstensibilty of HTML
   - thus is is also about who owns HTML and how BigCorp
     and Joe can claim ownership of anything in HTML.
   - this group rejected predefined class names. But it hasn't
     rejected taking in new @rel values. Why are there not the
     same principal rejection of "predefined @rel names" as there
     was to predefined class names? The obvious answer is the very
     thing that @rel values are strictly linked to the use of
     @profile. No one can claim ownership to @rel values or expect
     that rel values shall have any particular meaning other than
     in HTML 4 itself _unless_ one has linked to a profile that
     specifies it.

     So in a funny way, HTML 5 _relies_ on @profile. Despite
     the editor's opposition.

- When it comes to the more technical need to link to a profile, then
     - yes, there are some W3 technologies that seems to need it,
       such as GRDDL and RDFa.
     - yes, Dublin Core needs it.
     - yes, @profile represents a kind of versioning, and as Larry
       has been pointing out: versioning is especially useful
       for authoring tools.

John Allsopp's book on Microformats (from year 2007) points out 
all the places that microformats are used, such as in the user 
profile pages on Flickr. The fact that Flickr probably do not (?) 
use @profile, is that a good or bad thing? It is at least bad for 
the hordes of web authors that learn by looking into the HTML 
source = all of use. We must buy books on Microformats to discover 
  such details. Instead they could have used @profile and been 
open about it.


>> Regarding how many @profile-s you'd expect to find: So amount of @profile is
>> the answer both to the cowpath principle and this principle, as you see it?
> 
> The cowpath discussion doesn't seem to matter for now as neither of us
> are trying to apply the cowpath principle to @profile it seems, based
> on the above, right?
> 
> But I do think that if @profile hasn't seen much usage in the long
> time it has been specified, then either it isn't solving a real world
> problem, or it doesn't do it well, yes. At least I can't think of any
> other reason it hasn't been used.

One reason is hasn't been used is because e.g. Google isn't 
respecting the HTML 4 rules.

[1] http://microformats.org/wiki/rel-nofollow
[1] 
http://lists.w3.org/Archives/Public/public-grddl-comments/2008JulSep/0003.html
-- 
leif halvard silli

Received on Monday, 1 June 2009 00:31:59 UTC