W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Design Principles

From: Leif Halvard Silli <lhs@malform.no>
Date: Sat, 30 May 2009 04:17:58 +0200
Message-ID: <4A209756.1000507@malform.no>
To: Jonas Sicking <jonas@sicking.cc>
CC: Kornel <kornel@geekhood.net>, Anne van Kesteren <annevk@opera.com>, public-html@w3.org
Jonas Sicking On 09-05-29 22.35:
> On Thu, May 28, 2009 at 5:23 PM, Leif Halvard Silli <lhs@malform.no> wrote:
>> Jonas Sicking On 09-05-27 04.07:

>>>> That is only one of the questions (see above).
>>> The first two questions:
>>>>>>  * HTML 4 /has/ a method for defining meta data profiles:  A single
>>>>>>   web page that represents the profile. Do we need to change that
>>>>>>   cowpath?
>>> Is it a cow path? I.e. are there enough pages out there that *uses*
>>> @profile (i.e. not just has something in the profile attribute)? For
>>> example I wouldn't think that a page with only hCard data, but with an
>>> XFN @profile counts as stomping a cow path.
>>> If @profile isn't a cow path the above question doesn't seem to apply?
>> You apparently did not understand what I said.  [...]

> Sorry, I think I was unclear. I was not referring to how common
> profile pages are. I was referring to how common pages are that uses
> the profile attribute. I.e. how many pages contain a profile attribute
> linking to something.

I did understand what you said.

> A cow path is formed when a lot of people use a particular feature.
> The feature we're talking about is using the profile attribute. Is
> there data showing that a significant number of pages have the profile
> attribute set and thus use the profile feature?

	The cowpath principle is in itself not focused on the question 
whether "a lot of people are doing it". Instead, the text talks 
about considering cowpaths before considering /new/ methods.

So, before applying the cowpath principle, you should have an idea 
about a new feature. Then you should consider if solutions to this 
problem already exist before devising a new solution.

So if you do not bring a new feature to the table, then the 
cowpath principle doesn't apply.

	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.

>>>>  Also note that the design
>>>> principle talks about "consider cowpaths instead of inventing something
>>>> new". It doesn't say "consider if something is a cowpath, and if it
>>>> isn't,
>>>> then consider dropping the feature".
>>> IIRC there is also a design principle that talks about solving real
>>> world problems.
>> Of course there is. Here I was looking at the "cowpath" principle, though
>> because I claimed and claim that it has been misused.
> Sorry, I think I missed this, which could explain why we are talking
> past each other. You might be entirely correct that people might be
> misusing the cowpath principle. Can you point to where people have
> been doing this so that maybe we can clarify the principle to stop it
> from happening more.

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.

Regarding "solve real problems", the underlying logic here - when 
applied to an attribute that HTML already has, is, again, the 
unofficial "from scratch" principle.

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.)

>>> *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.

> If solves a real problem, then we should be able to find
> many pages that uses the feature to solve the problem. If there
> aren't, then otherwise the problem might not be an important problem
> to solve, or @profile solves it in such a poor manner that people
> haven't been able to use it correctly, or at all.

Regarding "poor manner", it has been suggested to use <link 
rel="profile">. This might be better, more XHTML 2 compatible, 
though less backward compatible.

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?

> Is there data to show that there are many pages that uses @profile at
> all, and even better, uses @profile to solve a problem.
> However earlier in this thread Kornel pointed out another method
> whereby processors can know that a page contains hCard data. Using
> context provided externally. I.e. if I point a hCard validator to a
> HTML page, that validator can guess that the page uses a hCard,
> without looking at the @profile attribute. In fact, Kornel even
> indicated that this method was common enough that he debated not even
> warning about a missing @profile attribute in his hCard validator.

I don't consider heuristics a better method. And I would expect a 
validator to show me errors.

>> You can also look at the RDFa specification, for instance. It includes a
>> @profile link as part of the specification [1].
>> It is said in the Design Principles that one should not use, as examples of
>> "code in the wild", pages that are found in HTML tutorials, specifications,
>> test cases etc. Such pages are not proof that anything is in use in the
>> wild.
>> That is fine. However, since @profile and profiles represents
>> /specifications/, we can, in this case not avoid looking at specifications.
> I think the wording here meant that we cannot look at the HTML4
> specification, and tutorials describing HTML4, to conclude that
> @profile is used.
> We can indeed look at pages that use @profile, and the specifications
> those pages point to using @profile.
> I hope that clarifies things?

It sounds as we are in rough agreement on this point.
leif halvard silli
Received on Saturday, 30 May 2009 02:18:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC