On Mon, 28 Jun 1999, Alan & Susan Mead wrote:
> I think a dictionary would be nice for the test, it is really more a
> training tool. Of course, this assumes we all share enough of our peculiar
> dialect that we can communicate in written form about Linux. I'm not
> willing to bet against that.
>
> AISI, the items we need to include on this hypothetical list are: (1)
> acronyms which might reasonably be much better known by their full, expanded
> form (e.g., perhaps PnP but not FTP nor TCP/IP); (2) jargon terms which have
> equally valid synonyms (e.g., any one of NIC, network interface card, LAN
> adapter, ...). Would we also want (3) acronyms which are clearer in their
> full expanded form (e.g., FTP or SLIP but probably not PPP nor IP)?
I think this does not solve the issue that was originally raised: what
words and acronyms are so common that we may use them and expect them to
be known. I still think we need to have a definitive list of them, with
or without explanation.
> Do Linux- and computer-oriented acronyms ever get translated (like FRG and
> USSR become (?) FDR and CCSP in their native tongue)? If so, we would want
> to include those sorts of acronyms as well.
That will be an issue for the test translators: we cannot anticipate all
possible local conventions. And note that many things are known by their
acronyms: we need not spell them out, and they are less likely to get
translated.
> As I described in my previous message, I would just list two fields, the
> preferred term and alternate terms. Would a definition be helpful (helpful
> enough to justify the trouble)?
Yes. Like Michael jang pointed out, the meaning of jargon tends to get
confused, especially between MS and Unix. So in some cases we need to
have a definition or at least a description of the concepts and words we
will be using. Just offering synomyms (which may not exist for things
with an acronym) will not be enough.
> Anyway, I've looked for lists of terms and all of them seemed unsuitable,
> most because they were waaay to inclusive. They tend to include arcane,
> basic, or specialized terms that we won't need.
>
> I propose an alternative to adapting one of these lists: (1) Someone (maybe
> me) strips out the jargon and acronyms in the objectives (and perhaps
> augmenting from the SAG and a couple O'Reiley books like Frisch's). (2) We
> post this list for comment. (3) We keep the revised list on-line during
> item-writing and (4) have the item reviewers both enforce the preferred
> terms and add to the list periodically.
This seems like a good idea, so please go ahead. But mind that the
stated goal was, to avoid jargon and abbreviations as much as reasonably
possible. It is not clear to me if you think we should not bother to
follow such a policy.
> This would provide consistency across exams because any terms that we
> include on Exam 1 get carried to Exam 2. New stuff for Exam 2 (if any) is
> added and carried to Exam 3. And so forth. It also seems more workable
> than writing an exhaustive list right away.
Note that the first level has 2 exams, which will be developed shortly
after one another. The second exam contains a distribution-specific part,
which is still under development.
--
#>!$!%(@^%#%*(&(#@#*$^@^$##*#@&(%)@**$!(&!^(#((#&%!)%*@)(&$($$%(@#)&*!^$)^@*^@)
Tom "thriving on chaos" Peters
NL-1062 KD nr 149 tel. 31-204080204
Amsterdam e-mail [EMAIL PROTECTED]
________________________________________________________________________
This message was sent by the linux-cert-program mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
