XML Schema and international Booleans

[Anders W. Tell]

Rick Jelliffe wrote:

>  From: Anders W. Tell <anderst at toolsmiths.se>
>
>  >Does this mean that I cannot create sub types of boolean which allows
> >other languages  than English?
>
> I think the XML Schema WG is working under the rationale that the only
> reliable approach is to standardize only a single way to do any one
> thing.

Then I have a hard time to understand why they are using highly flexible value-space,
lexical-representation concepts and then don't use them, as in the case of boolean.

> So there are only Gregorian dates using ISO 8601, and there is
> only one form of ISO8601 used, for example.

ISO creates international standards and im pretty sure that {true,false} is not
internationally accepted. Using zero (0) and one (1) is certainly more neutral and
logical.

Why not formulate a concept of "normalized" or "canonical" internationally accepted
lexical representation, and expand the definition/use of the lexical rules in order to
allow language variants.

>
> There has been a lot of debate about this between the W3C
> internationalization group, of course.  The issue comes down to whether
> to provide localization or internationalization.  I think, for XML
> schema, the non-localized approach (which is code for "English"--how
> shocking)  can be justified.

Frankly Im surprised that it appears that Internationalization is not accepted
by all parties involved in writing and debating international standards.
A "non-localized" schema version (XML Schema document) is OK however
if the use of english language is mandatory in parts of actual XML documents then
its a little to much anglosaxian cultural imperialism ;) for me.
Seriously, IMHO,XML Schema is *the place* to standardize Internationalization variations.

>
> Since, I think, XML Schemas is fundamentally intended for systems with
> something like Java at one end and something like SQL at the other, the
> reasons for localization are perhaps less than otherwise.  I think there
> is an assumption that input will go through something like a complex
> forms mechanism and output will go through something like XSL.

I don't think all applications will use complex software as XSL for a number
of reasons, space, complexity, time to implement etc.

>
> For controlled vocabularies, I suspect the better way to handle them is
> to have a Swedish->English  XSL script on the client.  There are
> thousands of languages, and I don't think it is reasonable to expect
> implementers to implement them.

And why should I be forced to use english as a norm ? Why not Swedish
or Esperanto, which is supposed to be the most universal language of them all.

Actually I heard a month ago that a Swedish university teacher (language department)
claimed that Swedish is the "closest to all other languages" language. Which
should indicate, if the person is right, that Swedish should be used as Norm
instead of English. Just a rumor i overheard ;)

> And it is dangerous to have standards
> made using words that the editors could not read.

Im not sure I follow you here. A human editor understand the words in the language/s
the person understands, a computer application editor (user agent) understands the
words in the schema,from which the xml elements are created from, supports.

>
> I am sure any ideas are welcome.  One approach would be to allow the
> schema developer to put in aliases for keywords.  Another approach would
> be to define entities &sant; and &falskt;  but then you would also need
> a DTD. Oops.

An idea would be something like this:
------------------------------------------
Define value space as: {binary logical false, binary logical true}
  (expressed in english since the spec is written currently only in English,
   the swedish spec. version would read: {binärt logiskt falskt, binärt logiskt sant})

Define zero ("0") and one ("1") as normalized lexical representation.

Add a enumeration's bindings concept:
 sequence of pairs of valuespace expression and lexical representation
 where each valuespace expression must express a subspace (or equal) of the
 value space.
  <enumeration-binding>
     <bind><value> true <value>  <literal> sant </literal> </bind>
     <bind><value> falskt <value>  <literal> falskt </literal> </bind>
     <bind><value> true <value>  <literal> on </literal> </bind>
     <bind><value> falskt <value>  <literal> off </literal> </bind>
     <bind><value> true <value>  <literal> oui </literal> </bind>
     <bind><value> falskt <value>  <literal> no </literal> </bind>
     <bind><value> true <value>  <literal> yes </literal> </bind>
     <bind><value> falskt <value>  <literal> no </literal> </bind>

     <bind><value> true <value>  <pattern> [Tt][Rr][Ue][Ee]</pattern> </bind>
     <bind><value> falskt <value>  <pattern> [Ff][Aa][Ll][Ss][Ee] </pattern> </bind>
  </enumeration-binding>

Med vänlig hälsning
/anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB  /
/  Anders W. Tell           /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)