[om] OM Floats (XML Representation)

[David Carlisle]

Bruce Miller said, quoting me
> 
> Yuck! Still seems horribly broken.  If my schema says we only accept 
> numbers greater than 10, or less than 10, I wouldn't want NaN in _either_ case!
> But, again, it's not clear that this would affect the OM spec, unless
> we expected people to derive a schema from the OM schema, and restrict
> OMF in certain instances (?)
> 
> > Also schema types get used in other places (specifically xquery/xpath/xslt 2)
> > and there of course operations such as equality testing and sorting are
> > defined. However I just checked and they don't follow schema there:
> > 
> > Despite Schema specifying NaN sorts high, XSL 2 draft says
> > 
> >   However, NaN values, for sorting purposes, are considered to be equal
> >   to each other, and less than any other numeric value. 
> > 
> > 
> > (note that this is for xsl:sort, the rules for < and =  operators are as
> > below)
> 
> These sound mostly sane; sorting should do _something_ with NaN's;
> which end they go to hardly matters as long as you specify it.
> If they added an isNaN predicate it seems like it would be 
> more or less complete & consistent.
> 

I've been looking at this again, and think really I agree with Bruce's
comments. We should still usefully be able to use xsd:double in the
schema for <OMF dec=... /> without impacting on the interpretation of
doubles within OpenMath itself (just relaxing slightly the regexp for
literal double values).


 
I'm not sure xsd is as broken as was claimed. The ordering and
inequality rules in schema relate to the ordering and inequality testing
done by the schema validator, they don't impose constraints on the
application.

There is only one NaN possible in a schema input as the only allowed
syntax is "NaN" there are no operations in schema that could generate
anything else. Given the semantics of schema validation testing, if NaN
was not equal to NaN, then if a schema constrained an element to only
have NaN then an XML file would never validate as an instance of that
schema; as even if it had NaN in that element, it would be not equal.
So all xsd is saying by NaN=NaN is that if a schema specifies that an
element must, or can, have NaN, then an instance that has NaN is
valid. This seems reasonable to me.

Similarly the ordering. Schema has taken an arbitrary choice and placed
NaN high, but the only thing this affects is the facets such as 
maxExclusive and minExclusive. IEEE NaN is supposed to be unordered wrt to
finite values, but that isn't really an option for schema. Given
a schema that specifies bounds on a double, the validator has to answer
valid or not given an instance that has NaN, the schema choice is
arbitrary but as I say it only affects validation. XSLT as an example
takes schema validated input but never uses that ordering, it has two
other interpretations, one for xsl:sort and one for <.
We should make a comment about this in the document (especially as we
have the hex attribute and so OpenMath NaN _can_ have multiple internal
values, but I don't think there is any harm, and possibly a lot of good,
in typing the dec attribute as xsd:double so it ends up typically in a
java (or C or C# or whatver) double (and so subject to the java
interpretation of ieee, not xsd's) rather than a java string.


David



________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems