As a test developer, I agree with Tom about making the list now. The main
reason is consistency. I think inconsistency or hidden assumptiojns about
meanings of terms will be confusing to the test-takers, will cause
time-consuming debate during item review, etc. It will not help make the
test understandable to non-English speakers. And if we go to translate
without such a list, different terms for the same thing can get translated
into different meanings which might not all be syonymous in the translated
language. If we mean one thing, we should use a single name consistently.
As a practical matter, we probably don't want a glossary to the test. We
would want to publish whatever materials and expect people to understand the
terms in real time during the test.
The list I'm imagining would have two columns. The first column would be
the perferred term and the second column would be a series of alternate
terms. Item writers could read through it once (so it should be short) and
grep it to determine the preferred term if they forget. The list would be
alphabetized by the first column. Something like:
Preferred : Alternatives
account: a login, a screen name, a passwd entry
CPU unit: [box that holds the] CPU, box, main unit, processing unit
DNS: domain name server, ip address resolution, name resolution
network interface card : NIC, LAN adapter, ethernet card, ne2000 clone
-Alan
-----Original Message-----
From: Jos Visser <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, June 27, 1999 5:54 AM
Subject: Re: Call for dictionary
>Hi,
>
>Wouldn't it be a better idea to work the other way around?
>I.e. make the tests, filter the jargon from them and then decide whether
some
>of them need explanation or be part of a glossary?
________________________________________________________________________
This message was sent by the linux-cert-program mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
