Re: [xsl] Non-English languages in XSLT, XML Schema grammars

[Eliot Kimber <ekimber@xxxxxxxxxxxx>]

Scott Trenda wrote:
> I'm a little curious about this too, but I would guess it relates to
> general cross-language capabilities in any computer language. The
> same question as applied to, for example, Javascript, doesn't make as
> much sense - should _fonction_ be recognized as the _function_
> keyword in a document with French encoding, or _関数_ in one with
> Japanese encoding? What about the original keyword when the encoding
> is different?
> 
> I'm certain this conversation has taken place before somewhere. I
> would, however, be interested to hear what the "official"
> standardized stance is on the issue.

There are a number of practical problems I can think of:

- You'd have to define the set of national languages, dialects, and
variants that would be supported for a given standard like XSLT or XSD.
That would have to be a normative part of the standard. This by itself
is probably impossible for most standards organizations to arrive at in
any reasonable period of time.

- You'd have to define a mechanism for indicating, on an element, what
national language, dialect, variant it was written in.

- You'd have to define the mappings from the base component names to
their corresponding values in each language, variant, dialect. This
would have to be a normative part of the standard.

- Every implementation would have to implement this mapping.

Just the Q/C on the standard language for such a specification (who's
going to verify that spelling of each non-Western value is correct in
every place it's mentioned in the spec, assuming you can find experts
for each language, dialect, and variant to even provide the values and
provide appropriate review?)

Of course, there's nothing preventing IDEs from providing some sort of
aliasing mechanism that would allow one to configure their local
development environment in any way that made sense.

Or you could develop a trivial XSLT to translate elements with localized
names to the standard names.

But trying to put that in a standard would just be nuts.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com