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

At 00/05/31 13:42 -0600, Arnold, Curt wrote:
>Unique representation of boolean, point 11.
>
>Even the current formulation does not capture the "yes"|"no" used in 
>various places in the XSLT spec.  I think that some minimal support for 
>lexical transforms as proposed in
>http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0022. 
>html would address this in a more satisfactory manner than the current 
>solution.

The solution in that mail would indeed allow to create
and use datatypes with localized representations.
Together with restricting the predefined representation
of 'boolean', this would be acceptable to the i18n WG/IG,
because it clearly separates abstract and locale-dependent
representation.

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
   is a toy example, localization of dates is not at all
   addressed. It is probably preferable to consider a
   solution that addresses all localization problems in
   an uniform way.

- It is unclear how conversion from one local representation
   to another would happen. Maybe one could construct an
   XSLT sheet that would take two corresponding schemas and
   one instance as an input and do the translations.
   Maybe one would build up an infoset, would change
   the schema, and would then automatically get the
   right result. But I'm not sure this would work,
   because the infoset stores the (localized) string value,
   not the abstract value.


>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.

Could you be more specific? What about documents that use ',' as a decimal
separator? What about documents that use ',' as a thousands separator?
What about documents that use some other kind of digits?
Either we address these issues, or we limit things to a single
representation. Everything in the middle is just muddying the waters,
and is counterproductive for internationalization.


>For example, XSLT cannot accept numerics with 'E' terms

This means you can't handle double or float with XSLT.
I don't see how this is changed if you restrict the
representation of doubles and floats to a single one.
Having XSLT being able to handle some floats and doubles
if they appear in some lexical representation is more
a source of wrong assumptions and bugs than a feature.


>or guarantee conformance to the formats.

XSLT allows to write out numbers in all kinds of formats.
You can definitely tell it to write them out so that
they conform to our proposals, or do you think you can't?
Could you give the details? If there are problems, it
should be easy to change the representation so that
we get rid of these problems.



>It would be possible to constrain the existing datatypes with a pattern to 
>follow the usages you described in case a particular schema author wanted 
>to assist signing.

Out of the wide variety of representations, the current spec
allows just an extremely narrow selection, but still more
than one in some cases. Such a solution is highly suboptimal.
It gives virtually everybody some work, and leaves it unclear
what the representation is for.


>TimeDuration arithmetic:
>
>The spec seems fairly clear that only integer values for terms of than a 
>second are allowed,

That would be a good thing. I'm not sure where I got the idea
that decimal fractions are allowed for e.g. years.



>however your point is valid and one that I have raised before.  However, 
>the only reason to not just
>express timeDuration as a real value interpreted as a count of seconds is 
>to allow imprecise timeDurations such as months or years since things like 
>contracts or lease payments can stated in imprecise
>durations.

Yes, and months or years can mean rather different things based on
the area of the world you are. We want all these cases covered, not
only one. If that's not possible, it's better to leave it altogether.

Also, please note that actual contracts, although they may express
things in terms of months or years, actually are up to a specific
date,...


>I can't find the exact comment, but we have had substantial discussion on 
>comparison of imprecise durations
>(http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/007 
>3.html) and it seemed reasonable to define, for boundary evaluation only, 
>a precise number of seconds to a year and a month.

That may indeed be in some cases reasonable. However, in the same mail, you 
wrote:

   "However, the recommendation must explicitly describe how
    this comparison should be performed."

The spec doesn't say anything about this. We made our comments on the spec,
not on something else.

Of course, this doesn't eliminate the problems that months and years
are highly calendar-dependent.


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.


Regards,   Martin.

Received on Wednesday, 31 May 2000 23:03:46 UTC