- From: James Graham <jg307@cam.ac.uk>
- Date: Thu, 02 Aug 2007 11:50:49 +0100
- To: Karl Dubost <karl@w3.org>
- CC: public-html WG <public-html@w3.org>
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