W3C home > Mailing lists > Public > public-html@w3.org > August 2010

RE: Letter to the Team Contact - ISSUE-30.

From: Paul Cotton <Paul.Cotton@microsoft.com>
Date: Fri, 13 Aug 2010 15:30:50 +0000
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, 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>, "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <E3EACD022300B94D88613639CF4E25F8087DBD68@TK5EX14MBXC138.redmond.corp.microsoft.com>
> 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.

I believe Leif is appealing the Chairs' decision as per:


3.5 Appeal of a Chair's Decision

Groups resolve issues through dialog. Individuals who disagree strongly with a decision SHOULD register with the Chair any Formal Objections<http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection> (e.g., to a decision made as the result of a vote<http://www.w3.org/2005/10/Process-20051014/policies.html#Votes>).

When group participants believe that their concerns are not being duly considered by the group, they MAY ask the Director<http://www.w3.org/2005/10/Process-20051014/organization.html#def-Director> (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. The participants SHOULD also make their requests known to the Team Contact<http://www.w3.org/2005/10/Process-20051014/groups.html#TeamContact>. The Team Contact MUST inform the Director when a group participant has raised concerns about due process.

Any requests to the Director to confirm a decision MUST include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions MUST be recorded.

Since Leif is an Invited Expert in the HTML WG he is entitled to send this appeal to the Director via the Team Contact.


Paul Cotton, Microsoft Canada

17 Eleanor Drive, Ottawa, Ontario K2E 6A3

Tel: (425) 705-9596 Fax: (425) 936-7329

-----Original Message-----
From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
Sent: Friday, August 13, 2010 11:02 AM
To: Philippe Le Hegaret
Cc: Michael Smith; HTML WG; Sam Ruby; Maciej Stachowiak; Paul Cotton; www-archive@w3.org
Subject: Re: Letter to the Team Contact - ISSUE-30.

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.


[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:



>> 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:31:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 August 2010 15:31:29 GMT