RE: Fwd: I18N Last call comments on Schema Part 2

Hello Arnold,

I'm sorry, but it seems that your comments are private comments,
but that I misunderstood them to be comments from the WG.

I think it would be worthwhile to do some design exercises
in the areas you indicate in case the WG wants to go into
that direction. But I don't want to go there at the moment
because:

- If the WG is not really interested, it's probably lost time.

- It is easy to cover a few cases, but to cover some cases
   is extremely difficult (see below), even if you expand your
   approach.

At 00/06/01 11:09 -0600, Arnold, Curt wrote:
>Martin wrote:
> >However, there are at least two problems with this:
>
> > It does not address localization of anything else than
> >   boolean (and maybe NMToken,...). The example with dates
>
>That comment was trying to be minimalistic and only addressed the simplest 
>case where the possibilities could be enumerated and a table of 
>substitutions could map a specific lexical representation to
>the base lexical representation.
>
>A more general capability could be built from the regex engine that has 
>already been mandated for a compliant parser.  Something like this could 
>create date type with a US style lexical representation
>for date:
>
><xsd:simpleType name="USDate" base="xsdt:date">
>         <xsd:transform>
>                 <!--  \3 expands third group, \1 expands first group  -->
>                 <xsd:replace match="(\d\d)/(\d\d)/(\d\d\d\d)" 
> replace="\3-\1-\2"/>
>         </xsd:transform>
></xsd:simpleType>

That's easy, but how do you do Islamic or Hebrew calendars?



> >Unique representations of numerics, points 12-15:
> >
> >While there may be some benefit of having a unique representation for each
> >value in the numeric values spaces for data signing, it would result in
> >the numeric datatypes being unusable for creating
> >schemas for the vast majority of existing XML documents and not be usable
> >with the current generation of XML technologies.
>
>Basically, the current schema datatypes are generally compatible with 
>common XML usage (which is dominantly Anglo) and are hostile to non-Anglo 
>lexical representations.  The numerics representation
>you described would be hostile to 99.99% of XML documents with 
>numerics.  I would be much more in favor of expanding schema datatypes to 
>enable non-Anglo representations than restrict schema
>datatypes.

I think you misunderstood some of our comments. We do not want one
single lexical representation for all numeric datatypes. We want a single
lexical representation for all types derived from the same base type,
i.e. if something is float or double, it has an E. If something is
decimal or derived thereoff, it doesn't have an E.

Which to use is the schema designer's choice, but the coice has to be made.


> >>By the way, your mail also mentioned the case of time zones producing
> >>multiple representations. I forgot about that when writing up my
> >>comments, it should be added.
>
>I think this is the worst offender of the multiple representation cases 
>since it really does tempt you to communicate something else (the time 
>zone) in the format of a value.

I agree. The time zone may be interesting for dates, but not for more
precise times.


Regards,   Martin.

Received on Friday, 2 June 2000 05:50:17 UTC