W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2011

Re: dropping "title" column from specifications table?

From: Linss, Peter <peter.linss@hp.com>
Date: Mon, 26 Sep 2011 20:31:14 +0100
To: fantasai <fantasai.lists@inkedblade.net>
CC: "public-test-infra@w3.org" <public-test-infra@w3.org>
Message-ID: <2D122139-DEAB-4467-BA82-0CB448D95477@hp.com>

On Sep 26, 2011, at 11:43 AM, fantasai wrote:

> On 09/26/2011 10:31 AM, Linss, Peter wrote:
>> Hi Mike,
>> For the CSS specs, many of them have a rather long formal title and a significantly shorter name that's commonly used for them, i.e.:
>> CSS 2.1: Cascading Style Sheets Level 2 Revision 1
>> CSS3 Images: CSS Image Values and Replaced Content Module Level 3
>> CSS Lists: CSS Lists and Counters Module Level 3
>> Using the 'spec' short name is not appropriate for general UI as it really is meant to be used, as you said, as a DB key and in URIs, and given the long formal titles of some specs, having a shorter name is very helpful in the UI.
>> I accept that for many specs the 'title' and 'description' fields will simply be identical.
>> If it helps, consider 'title' to be a version of the URL short name suitable for UI use. (Which is sometimes more of a change than a simple transform, like 'CSS-STYLE-ATTR': 'CSS Style Attributes'.)
>> While the harness doesn't make much use of the 'title' field, Shepherd does, as it has more exposure of the specs in the UI. I want both the 'specifications' and the 'sections' tables to be sharable between the tools. (In fact for a setup using both Shepherd and the harness it makes more sense to maintain the spec and section tables in Shepherd as that's the first point of exposure between tests and specs.)
>> So bottom line, I really think that field is necessary and it makes sense to keep it around. The pattern of a short name and full name is also used in other tables, like 'formats'.
> If that's the intended use, then maybe there would be less confusion if the
> fields were titled "Full Title" and "Short Title"?

The field names are internal and are only seen by developers. I don't really care what they're called (the names are carry-overs from old code), but I don't think the cost of changing them at this point is worth the benefit. And, as I said, the pattern is used in other tables where 'title' and 'description' are appropriate field names, so there's benefit to keeping the naming consistent across tables.

That said, there's no reason the internal field name should be exposed in the UI, so the spec editing UI should describe the field in whatever manner makes the most sense to the user.

Received on Monday, 26 September 2011 19:32:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:32 UTC