Re: Formal Recorded Complaint

Karl Dubost wrote:
> 
> Just to illustrate why some arguments can be misunderstood sometimes 
> (and there are more than two sides). James it is just taken as an 
> example, so let's not make it a personal issue.
> 
> Le 1 août 2007 à 06:29, James Graham a écrit :
>> I would argue that semantics-for-the-sake-of-semantics is not Solving 
>> Real Problems (c.f. the design principles).
> 
> Why this sentence is an issue?
> It paints a black and white situation. it characterizes two camps:
> 
> * one as a bunch of (not realistic) academics
> * one as a bunch of (realistic)     engineers.

I assure you that wasn't the intention, although I see how you could interpret 
it that way. I hope it will be useful to clarify my (apparently poorly 
expressed) intent.

I think there are two issues here which maybe need to be disentangled: a) the 
cited design principle and b) the message that I was actually trying to convey.

We have a (draft) design principle that states:

"Solve Real Problems

SolveRealProblems: Changes to the spec should solve actual real-world problems. 
Abstract architectures that don't address an existing need are less favored than 
pragmatic solutions to problems that web content faces today. And existing 
widespread problems should be solved, when possible."

Clearly, in order to apply this principle we must have some level of shared 
understanding about what constitutes an "actual real-world problem". I don't 
believe consensus on this issue exists as, for example, Rob Burns has 
occasionally suggested introducing elements, or retaining attributes, on the 
basis that they improve semantics (Rob, please correct me if I have 
misunderstood you). I do not believe that such a reason is prima facie 
sufficient to fulfill "Solve Real Problems", rather one needs to identify an 
/additional/ problem (beyond greater expressiveness of the language) that can be 
solved by including a particular markup construct (or rather the reverse; one 
needs to identify a problem and then design markup that solves it). Some 
consensus on the correct interpretation of this design principle will make 
applying it much easier.

Once we have a set of design principles with well agreed interpretations, I hope 
it will be possible to (with careful consideration of the wording) to point to 
the design principles as a reason for not accepting an argument or a feature.

However I was not expecting to achieve consensus on (or even really discussion 
of) that issue in the message I posted - although in retrospect I probably 
didn't make that clear. My actual aim was to elucidate a particular thought 
process with regard to accessibility; in particular the kind of evidence that 
could lead _me_ to believe that @headers is a bad idea. I think this is useful 
because, as I understand it, it is quite different from the kind of thought 
process that a "category A" person would have. In order to follow this thought 
process it is necessary to understand the underlying assumptions that I have; 
"semantics for the sake of semantics is not a sufficient reason to include a 
feature" is something I believe and is relevant to the argument so it is 
necessary to accept that as an axiom in what follows.

Unfortunately, it is not at-all clear to me that I was successful in 
communicating the point I was trying to make. Hopefully I will be more 
understandable in the future.


-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Thursday, 2 August 2007 10:51:05 UTC