On 11/08/2001 11:53:30 PM DougEwell2 wrote:
>I found the Web site I had mentioned...
OK. I've had a chance to look over the ISO 9995 docs. It is unfortunate
that Part 1 wasn't available, but then the CEN document you provided a
link to seemed to contain everything from all parts of 9995 that was
likely to be of use (though granted I'm inferring that since I haven't
actually seen all parts of 9995).
What I don't find all that useful about 9995 is it's focus on prescriptive
requirements for resources that meet the needs of a specific community of
users (Europeans). The thing that was the single most interesting item of
all was one brief paragraph in the CEN document:
<quote>
UK has proposed an international register of keyboard layouts which has
resulted in the SC 35 secretariat
investigating the material and juridical possibility to create and
maintain, on a web site, a data base
containing national keyboard layouts as communicated by the NBs. AFNOR, in
charge of the SC 35
secretariat and of the SC 35 Internet site, recently agreed to put these
documents at the site under the
NBs' control.
</quote>
So, sounds like they're thinking of doing the same kind of thing you've
been interested in, Doug.
Actually, I'm not too concerned about who does it. It shouldn't matter if
one body or 7 bodies or 35 bodies get involved in documenting keyboard
layouts. What does matter are the following issues:
1. there needs to be a common format for documenting the descriptions
2. there needs to be a consistent means of layout identification so that
if two bodies have descriptions of the same layout they should have the
same id
3. wherever the descriptions are located, there should be a convenient
mechanism for locating the description
I don't have any particular thoughts on item 2. I'll make some further
comments on 3 and 1:
The issue involved in item 3 is one of the key issues being addressed by
OLAC -- the Open Language Archives Consortium (www.language-archives.org).
This consortium includes various agencies that have archives of language
and linguistic data, and agencies that are involved in various aspects of
language engineering (e.g. ELRA). OLAC is still in developmental stages,
but is being sponsored by a significant and growing group of agencies. At
any rate, the main point about OLAC is that they are implementing the
mechanisms developed by OAI -- the Open Archives Initiative -- to allow
data to be maintained by multiple agencies and housed at multiple sites
but for a common set of metadata about those holdings to be harvested in
such a way that from any number of portals one could find any of the
resources in any of the holdings that matched desired criteria. So, my
point is that for people involved in our area of language engineering and
engaged in activities like documenting keyboard layouts, encoding
conversion mappings, writing system descriptions, etc. it makes good sense
for these kinds of resources to be incorporated into the OLAC framework
and to benefit from what that OLAC can offer. Certainly for SIL's part, we
expect to be making documentation of this sort that we provide assessible
within the OLAC framework.
Next, in relation to item 1, I gather, Doug, that you are working in terms
of the A-E x 00 - nn grid presented in ISO 9995. I see several issues with
this that need to be addressed:
i) It isn't clear to me how to identify the 00 reference column on a
physical keyboard. As I read their description of layout requirements,
e.g. in 9995-2, I could not figure out how to relate their general
keyboard arrangement (clause 7.1 and table 2 on p. 3) or their harmonised
48 graphic key keyboard arrangement (clause 7.2 and table 3 on p. 4) with
the keyboard on the machine I'm using at the moment (a notebook, but the
fact that it's a notebook is, I think, irrelevant since the problem really
has only to do with the layout of the ctrl, shift, caps lock and tab keys
-- though maybe the laptop is relevant, but then what use is something if
we can't work around such issues). Perhaps it might be possible to resolve
this by simply stipulating that the left shift key is position B00 (say),
though we may still run afowl of the next two issues.
ii) Somewhat related to but more general than item (i) is the fact that
different hardware can be significantly different from one another, and in
ways that may create potential ambiguities. E.g. I'm not terribly familiar
with hardware used in Far Eastern countries, but I've seen documents
indicating a number of additional keys (relative to US hardware, for
example). Is there potential that these additional keys could create
ambiguity when set against the grid presented in 9995? For instance, the
keys in the A row would not necessarily line up with columns for the other
rows. Similar issues can arise on hardward from other parts of the world
when keys along the A row or keys at the left or right edges vary in size
and don't stay within clear column arrangements.
iii) Two structurally-different physical layouts may be functionally
equivalent; i.e. they have the same set of keycap symbols but in different
relative locations. For example, some US keyboards have the backslash in
one place and some in another, but in both cases the key with the
backslash symbol on the keycap is used to enter "\".
iv) There is a distinction between physical layouts and logical layouts,
in the sense that I can use my US English hardware together with a logical
input method for Thai. It needs to be made clear what is being described.
v) There are issues involved in the relationship between physical and
logical layouts, particularly given the fact that two
structurally-different physical layouts may be functionally equivalent
(see item ii). In some situations, it may be desired that a logical layout
should match the keycap shapes (assuming some particular set of keycap
shapes) regardless of where they are located. For example, if someone
creates a Hebrew keyboard layout that is intended for use by speakers of
European languages who are thoroughly familiar with Latin script but have
only limited familiarity with Hebrew script, they may want to design the
layout in such a way that the zayin, yod and qoph (for instance) are
entered on the keys that have "Z", "Y" and "Q" keycap shapes respectively,
regardless of where those keycaps happen to be located on a particular
piece of hardware. On the other hand, in other situations someone may want
a logical layout to follow a specific spatial arrangement regardless of
the location of keycap shapes on given hardware. So, for example, if
someone is creating a Hebrew keyboard layout intended for people
accustomed to physical Hebrew keyboards (e.g. so that they can work or
different equipment in multiple locations), they may want the sin/shin key
located immediately to the right of the caps lock key regardless of what
keycap occurs on the physical hardware.
Now, obviously in all of the there are issues that particular
implementations would need to deal with. But there are issues for
*descriptions* of layouts as well: a description of logical layouts needs
to indicate whether it is intended to be defined on a strict spatial
basis; or whether it is intended to be defined on a mnemonic basis
assuming some underlying physical layout, in which case the assumed
physical layout also needs to be specified.
Finally, also related to item 1 but unrelated to the reference system
used, there is the issue of what kind of file format gets used to
represent this. In all things of this sort, I think the documentation
should be plain-text processible with some form of text-based markup. Of
course, our markup flavour du jour (du décade) is XML -- of course, saying
XML is only partially complete: what really matters is the schema / DTD.
Some thoughts.
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
This archive was generated by hypermail 2.1.2 : Mon Nov 12 2001 - 00:43:32 EST