Re: issue #19

This issue (#19, and #99) was discussed yesterday at the telecon.  The 
resolution is to write up the issue, with examples, and move the discussion 
of the remaining open bit of the issue to the IG list.

At 03:53 PM 10/17/02 +0900, Karl Dubost wrote:

>At 10:16 -0600 2002-10-14, Lofton Henderson wrote:
>>1.) With the aggressive publication schedules, it is not possible to 
>>coordinate with QA Glossary (esp. for new terms).
>
>Not a good reason... What you are saying is a coordination problem not a 
>real issue. It's not difficult to edit the QA Glossary... if Editors send 
>their new definitions to the QA glossary Editors

I strongly disagree.  It is hard enough to publish, without asking the 
editors to have to coordinate with yet another document.  This would be 
true regardless of the timeliness of updating the QA Glossary.  For one 
thing, the definitions would have to be negotiated and approved for the QA 
Glossary.  But even without that, it is just one more hassle in an already 
complicated and tedious process.

There was consensus at the telecon about the process/procedure 
aspects:  the GL documents may have definitions sections during their 
development; and, harmonization with QA Glossary is not required until 
later document stages when the document stabilizes (e.g., after LC, at CR, 
or whatever).

By "harmonization" I mostly mean migration of new terms into QA Glossary, 
negotiation of their definitions, etc.  It was also agreed at telecon that, 
if the term is already in the QA glossary, it will be reference by link and 
not contradicted.  The remaining open question concerns supplementing and 
extending the definition with contextual and exemplary material that is 
useful in the context of the particular GL document.

>AND it's even easier to maintain than 3 glossaries in 3 specifications.

I disagree again.  From my recent experience -- 8/26 publication -- it is 
trivial and no work at all for the GL editor to keep a Definitions 
section.  In fact, it actually helped me in the editing process, to have 
definitions of SpecGL terms right there, for reference while editing.

>>2.) In any case, some terms may not be appropriate for the general QA 
>>Glossary.
>
>So we can add them :) all people would benefit of these definitions. The 
>efforts of glossary inside W3C is to collect in one place all the used 
>terms to avoid disparate definitions in different documents which become 
>rapidly unmaintanable.
>
>>3.) Appropriate terms may eventually migrate into QA Glossary, with an 
>>appropriate definition for that document.
>
>counter-effective.

I don't understand this argument.

As indicated above, if the term is in the QA Glossary -- including 
migration from a developing GL WD -- then the GL WD will reference it and 
any additional bits in the GL document will not contradict it.


>>4.) It is appropriate and desirable in a per-Framework "Definitions" 
>>section to supplement and expand upon the generic, terse QA Glossary 
>>definitions, in the style of some of the WAI guidelines documents. This 
>>allows for contextual, functional, and exemplary information, that 
>>relates the term to the context of the particular framework document.
>
>it's going against the effort of Olivier and people of the QA Team which 
>try to make a global glossary to avoid different definitions of the same 
>terms among W3C Specifications.
>http://www.w3.org/QA/2002/01/Glossary-req

I don't agree that it undermines that effort.  If a definition appears in 
more than one place, the core definition is the same everywhere -- the QA 
Glossary version.  So there are not "different definitions".  The 
additional material proposed for each GL further explains the concept in 
the context of the particular GL document.

(Have a look at the WAI documents for an example, to see why I like the 
contextual/exemplary supplemental stuff -- I found their Definitions 
sections to be a *huge* help, when trying to read them for the first time.)

-Lofton.
-Lofton.

Received on Thursday, 17 October 2002 11:57:29 UTC