[om] OM Floats (XML Representation)

[Bruce Miller]

David Carlisle wrote:
> Bruce
> 
>   If Schema are just used to validate OM documents, how could their
>   broken description of NaN's affect OM?  Could the schema ever come into
>   play transforming an OM doc, using the broken arithmetic?
> 
> In schema itself it probably doesn't make any difference for the foat
> and double themseleves, but it does affect validation against derived
> types.  For example if you define a restricted type based on float using
> maxExclusive then you will exclude NaN as (according to XSD) NaN is
> larger than all other values including INF, conversely if you restrict
> using a lower bound, then NaN will be allowed as a value of the
> restricted type.

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.

> similarly despite schema specifying that NaN values compare equal,
> XPath/Xquery specifies
> 
>   Each comparison operator returns a boolean value. If either, or both,
>   operands are NaN, false is returned. 
> 
> So there is precedent for using the schema type but explictly specifying
> different comparison and sorting semantics than the schema rec.

Perhaps I'm still too focused on `validation', but even if my schema
uses xsd:double, I can hardly be bound to XSchema's semantics in
my application!?

> This might possibly be more useful in tems of code generation than using
> a regexp constrained string, however there might be some merit in (as
> currently) avoiding these issues with xsd:double and sticking to
> string. Comments welcome:-)

I can go either way --- but as an aside, I notice there's a decided preference
for RelaxNG among some people (w/ James Clark & Norm Walsh, apparently among them).
I know you've worked with both RelaxNG & XSchema.  Is one form, or the other,
intended as the prescriptive def of OM?  If I've interpreted RelaxNG correctly,
they've sidestepped the issue by not defining double at all ???
At any rate, until the dust settles, perhaps a good strategy would be to not
get to bound to any of the unique features of either one.

> David
> 
> 
> 
> 
> 
> 


-- 
bruce.miller at nist.gov
http://math.nist.gov/~BMiller/

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