Dated Version of the QA glossary.

Hi,

this a proposal to close this long standing action item.: Karl & Mark 
Propose the details for managing dated Glossary versions.

Right now, the page has for address
	http://www.w3.org/QA/glossary

I propose to keep the address at this place and to write a redirect 
in .htaccess

RedirectMatch temp /QA/WG/glossary(.html)?$ 
http://www.w3.org/QA/WG/2003/03/glossary-20030325

As usual we will have the Latest, Previous version, and This version 
Information for the links.

I propose that  a new version of the glossary is issued at the same 
time than the specification are published. To avoid differences 
between the specification and the glossary and to help to maintain as 
much as possible the QA glossary as meta glossary of possible 
refinements in specifications.



* This proposal relates somehow to the one, we have to deal for the 
more general glossary project:

Karl, Mark, and Wendy
(owned by Karl) coordinate with WAI and develop a how-to draft for 
entering definitions into the glossaries 2003-02-17
http://lists.w3.org/Archives/Public/www-qa-wg/2003Jan/0018

We discussed at the meeting in Seattle that we have to define a 
general process for WG to define information inside a specification 
and outside, and how does it relate to the W3C glossary?

When a WG is defining a term, it would be necessary to have to 
top-down approach for the editor:

1. Look if the word is defined in the general glossary.

	1.1 If it is, use this definition and refer to the general 
glossary for its definition.
	Comment: This method implies that the definition in the 
general has to be fixed somehow because it implies a dependency 
between the spec and the glossary. Or maybe each definition has a 
kind of unique identifier with a versioning of the definition?

	1.2 If the definition is not satisfying and you will have to 
refine it for your own purpose, define your words as a refinement of 
a more general definition, but do not make it contradictory of the 
main glossary.

	1.3 If the definition doesn't exist, use the markup defined 
by the general glossary to make it automatically extractible. So the 
general glossary can increase the numbers of words defined.
	Comment: At this stage, we could offer a templating system or 
a mini-glossary engine included in the bigger one to help people to 
create the right markup for their spec.

	1.4 glossary legacy
	What will happen when we will start to create the glossary 
and have conflicting definition for the same word. I guess we should 
collect them but at a point recommend one definition on the others.

2. Translation of terms.

	2.1 Differences of translations in time
  	The translations are not normative because some translations 
are different depending on the translators. The goal of the glossary 
is to reduce the discrepancies between the different specification 
and the translated terms. There will be a need of a consensus at a 
point. What's happening when a first person translate a first term 
but a second translator comes to contradict it.

	2.2 Differences of translations between family of languages
	It can happen that the translation varies depending on the 
version of languages, like in color/colour or differences between 
FR-fr, FR-ca, FR-ch, etc.

	2.3 Definition
	Should we have also the translation of the definition. The 
rationale for this one is that sometimes it's very helpful to 
translate the definition to explain the meaning of a word and so to 
have a better translation of the context when inside a spec.


-- 
Karl Dubost / W3C - Conformance Manager
           http://www.w3.org/QA/

      --- Be Strict To Be Cool! ---

Received on Tuesday, 25 March 2003 17:52:50 UTC