- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 13 Aug 2010 17:01:36 +0200
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: Michael Smith <mike@w3.org>, HTML WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, www-archive@w3.org
Hi Philippe, I don't know if your question perhaps indicate yet another unclarity in the decision document. The Decision namely states that there are two ways to appeal it, and I believed that it was very clear from my letter which option I chose. From the Decision: ]] Appealing this Decision If anyone feels they have not received due process, or that their concerns have not being duly considered in the course of reaching this decision, they may make their concerns known to the Team Contact (Mike Smith) who will notify the Director. If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request. In the case of this issue, the Chairs have agreed to forward Formal Objections right away for expedited processing. Anyone who would like to take either of these steps should first read the Review of Arguments Presented, below. [[ By the use of the phrase "either of these steps", the decision expresses that there are more than one way to appeal the Decision. According to my reading, the Decision describes two ways: EITHER one may make the concerns known to the Team Contact Mike Smith OR one may file a Formal Objection. I have chosen the first option, and I now expect the Team Contact to take up my concerns with the Director. I am not certain what the Director then is supposed to do. But my hope is that he agrees with my concerns, and that he have the power to rescind the Decision and (or) instruct the co-chairs to rescind their Decision and draft a new Decsision where they look at the issue anew and where the concerns that I take up are given the treatment that should be expected. I don't mind if the Decision is dropped altogether - a new or supplemental change proposal process can be initiated before a new Decision is formulated. Are my expectations about what the Director has the power to do too high or wrong? I have not formulated a Formal Objection, because I don't want to use that instrument when the problem simply is that the Decision on several levels is incomplete. (And I am not alone in questioning the quality of this Decision. [1]) A Formal Objection if this initiative does not lead anywhere, is of course a possibility, which I haven't considered yet. Leif [1] http://burningbird.net/node/118 Philippe Le Hegaret, Fri, 13 Aug 2010 09:54:22 -0400: > Hi Leif, > > are you raising a formal objection to issue-30? > > Philippe > > On Fri, 2010-08-13 at 15:23 +0200, Leif Halvard Silli wrote: >> Mike Smith, >> >> I write to you as Team Contact, about my concerns with regard to the >> HTMLwg Decision on ISSUE-30: >> http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision >> A CC goes out to the HTMLwg co-chairs, to public-html@ and www-archive@ >> >> My time is limited, so if you feel that some issues are >> under-documented, then please tell me and allow me to follow up. >> >> Concerns >> -------- >> >> 1) Errors in the decision document >> >> The are many errors in the decision document - some of which the chairs >> have already admitted to. The document fails to make an accurate >> summary of many many things. Examples: Firefox is listed as a >> "successful" implementation of @longdesc, despite that Jon's objection >> state the opposite. And a few successful implementations that _are_ >> listed in the objections, are omitted as such examples in the decision >> document: Jaws, iCab. And Charles's presentation of @longdesc (in his >> objection to the zero-change proposal), is presented as if he says that >> @longdesc is the only way to technically link to a long description. >> These and a few other errors (which probably are just errors and not >> conscious errors) are easy to check simply by reading the relevant >> objections and proposals, undermines the trust in the decision as a >> whole. >> >> 2) Criteria for use of certain words >> >> The decision demands things of the change proposers and objectors, >> which the decision fails to live up to itself. One of those demands are >> very specific criteria for the use of certain words. Example: the >> decision (unduly, in my view) complains about lack of definition of >> «the adjective "successfully"» (which is a an adverb, btw ...). >> >> However, the decision itself operates with several words for which it >> provides no criteria. Examples: 'use case' and 'require'. It is >> entirely unclear what kind of 'use case' the document wants, though, >> for the most part, the document seems to look for technical reasons to >> have @longdesc. >> >> To my mind HTML4 describes a use case: [1] "a link to a long >> description of the image. This description should supplement the short >> description provided using the alt attribute.". There are no links in >> HTML4 or HTML5 other than @longdesc that have this semantic. As such it >> @longdesc is required. (The proposal to keep @longdesc duly links to >> HTML4, and so the decision have every reason to discuss what HTML4 says >> - but fails to do so.) >> >> 3) Concerns not being duly considered >> >> Example: Longdesc link rot was cited as a problem both in the >> objections, in the zero-change proposal _and_ in the decision document. >> In my objection, I pointed out that this - in a way - automatically >> becomes solved as soon as @longdesec is made valid: by making @longdesc >> un-obsolete, HTML5 conformance checkers must - obviously - start to >> conformance check the @longdesc URL. (Explanation: in the HTML4 >> validator, no URL validity checking is performed whatsoever, whereas >> validator.nu does check URLs, as long as the attribute isn't >> obsolete.) >> >> I filed a bug about this, to make sure that conformance checkers would >> do this, and the link to the bug is in my objection. >> >> However, not a single time does the decision document that it has >> considered this simple and obvious argument. Instead, the decision >> document states it to be "uncontested" that "more work is needed to >> make longdesc useful". However such a general statement is hardly >> relevant when the required work, at the most basic level, simply >> involves moving @longdesc from the list of obsolete attributes to the >> list of valid attributes. >> >> 4) No evaluation of @longdesc from a semantic angle >> >> This goes back to my 'use case' critique under 2) above. In the >> subsequent debate, I took up an idea that I picked up from Lachlan. >> Namely that rel="londesc" (<a rel="longdesc" href="*"><img alt="short >> description" src="*"></a>) many times could be used as a replacement >> for the @longdesc attribute. (The exception being when there is already >> a link on the IMG. Another exception is on iframe elements, which HTML4 >> also allows: the <a> element is not allowed to be a wrapper around an >> iframe element.) The response has been that rel="longdesc" is worth >> looking into. If we see @longdesc as shorthand for the - yet undefined >> - rel="longdesc" micro format, then should be obvious that the issue is >> about semantics. >> >> (In my objection, I compare @longdesc with a special kind of link, >> although I fail to mention the rel="longdesc" parallel.) >> >> However, the only time the decision uses the string "semantic" is when >> it states the following: "A number of use cases for semantically rich, >> structured descriptions of images were provided, however those use >> cases are abstract and don't directly and specifically require the >> support of a longdesc attribute". >> >> By this definition, then even what HTML4 says about @longdesc is >> abstract! >> >> Apart from the situations when <img> already has a link as well as the >> <iframe> use case (see above), then it is probably impossible to find >> concrete examples of use cases when it is _technically_ impossible to >> solve the problem unless the language includes @longdesc. However, >> _semantically_ the language currently has no other method than >> @longdesc for solving the issue. But I look in vain for a discussion of >> this problem in the decision document. >> >> [1] http://www.w3.org/TR/html4/struct/objects.html#adef-longdesc-IMG >> >> This letter of concern is mostly a summary of points I have made in the >> following letters: >> >> http://lists.w3.org/Archives/Public/public-html/2010Aug/0117 >> http://lists.w3.org/Archives/Public/public-html/2010Aug/0119 >> http://lists.w3.org/Archives/Public/public-html/2010Aug/0128 >> http://lists.w3.org/Archives/Public/public-html/2010Aug/0129 >> http://lists.w3.org/Archives/Public/public-html/2010Aug/0140 >> >> With regards, >> Leif Halvard Silli >> HTML WG Invited Expert >> >> > >
Received on Friday, 13 August 2010 15:02:18 UTC