RE: [xtm-wg] Fixing language.xtm and country.xtm

["Mason, James David (MXM) " <mxm@ornl.gov>]

Having watched this discussion for a couple of days, I'd like to comment,
starting from Patrick's observation:

> -----Original Message-----
> From:	Patrick Durusau [SMTP:pdurusau@emory.edu]
> Sent:	Tuesday, June 26, 2001 7:26 AM
> To:	xtm-wg@yahoogroups.com
> Cc:	Lars Marius Garshol
> Subject:	Re: [xtm-wg] Fixing language.xtm and country.xtm
> 
>  
> 
> Bottom line is: Communities are not formed by self-selected individuals
> who then act as gate-keepers, or at least not successful ones.
> Communities are formed by people who share an interest in an idea or
> goal and who are willing to put up with each other while they work
> towards an imperfect realization of that goal.  
> 
> 
What this group (no matter what its current name is or how it's chartered or
under whose auspices it's running) has come up against is a problem that we
ran into long ago in ISO: the need for registration authorities.

You need a registry (a place to register things like PSIs), a registration
authority (somone to run the registry), and an online place to keep what's
in the registry. Right now, we don't have any of those things, and we don't
even know that we'll be in a position to have them by Montréal or even
Orland0>

Let's step aside from the immediate questions of language.xtm and
country.xtm. 

There's a long recognized need for places to keep lists of constant items
that people can refer to. Some of those lists are pretty basic, like the
contents of coded character sets (the following history is greatly
ovesimplified; Martin Bryan could give you a more-detailed explanation). The
great grandaddy of those was ASCII, which was established by American
National Standard X3.4. For that basic 7-bit character set with an American
English bias, it was enough to enumerate everything in a standard. But as
soon as someone wanted to internationalize it the least bit, there was
suddenly a prblem of keeping up with versions. X3.4 moved into ISO as ISO
646, and then someone needed to keep up with things that replaced "$". ECMA
(European Computer Manufacturers Association) wound up seeting up a
registration authority for variants. When the code set went from 7-bit to
8-bit in ISO 8859 (ISO Latin I), ECMA's role expanded. When the
Western-European bias of ISO 8859 needed replacement, the work on ISO 10646
was started, again with ECMA sponsorship. That work stalled, and the UNICODE
consortium came along with a proposal. The result is that UNICODE has become
the de facto RA for the contents of the ISO standard.

RAs are useful when they are enduring organizations, sort of after the model
of standards bodies. The down side is that they require a certain
bureaucracy and other aspects of corporate survival. 

Take, for example what happens when one goes out of business. UNICODE/ISO
10646 is just a list of coded characters. That is, it just deals with bit
combinations (or hex representations . . .). Althought the published
versions of the standard show printable characters associated with the bit
combinations, those actually aren't standardized. (There's a real difference
between hex 61 and the letter "a" in Arial, which is what my computer is
displaying.) There's a separate registration authority for the glyphs (the
abstract printable images) under a different standard, ISO/IEC 10036. We've
just been through a problem because the RA, which was formerly AFI
(Association for Font Information Interchange), went out of business.
UNICODE considered taking over the RA, but it wound up with GLOCOM, an
institute at a university in Japan.

Lots of other organizations have been RAs. GCA is the RA for ISO 9070, which
nominally does "SGML Public Text".

What you're wanting is a place to put PSI data (BTW, the language and
country codes have an RA under ISO TC 46). 

We didn't think of this need when we started ISO 13250. (One of the
questions on the proposal form for a new standard is, "Will a Registration
Authority be needed?" We answered, "No.")

Now that we've been working with TMs for a while, we realize the ISO
decision may have been wrong. I've been having offline discussions with
Newcomb and Biezunski since we got back from Berlin. There are some PSIs
attached to XTM that really need to be online in a fixed place (we don't
want the typical XML Namespace dead URI problem). Those PSIs are even more
fundamental than country.xtm and language.xtm. They really need to be in a
PERMANENT place. One idea that has been suggested is that they need PURLs,
and the place for PURLs is, of course, OCLC. 

That doesn't mean that OCLC is the right place for a RA for all the world's
PSIs. I doubt they'd want that. But we might need to be thinking about
preparations. Actually we need two things: (1) a standard to provide for the
RA and (2) the RA itself. Item 1 is appropriate work for SC34 (those of you
who work in SC34, start thinking about it!); Item 2 might be something OASIS
could do.

I'll be glad to explain the mechanics of this if anyone wants to take it up.

Jim Mason

James David Mason, Ph.D.

Y-12 National Security Complex
Bldg. 9113, M.S. 8208
P.O. Box 2009
Oak Ridge, Tennessee 37831-8208

+1 865 574 6973

Chairman, ISO/IEC JTC1/SC34
http://www.y12.doe.gov/sgml/sc34/ornlsc34oldhome.htm


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/