[xsd-users] Double trouble

[Esben Skovenborg]

	Hi Boris,

Thanks for your quick reply. 

Although my operator<< hack does solve my immediate problem, I would
prefer not to have to patch the libxml runtime. 
I think it would be most natural to map xsd:double to C++ double, as in
your "even better solution", below. What would I need to do?

A related issue is the handling of +/-INF and NaN 'special values' of
xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will
these values be supported by the XSD 3.1 serializer? and by the parser?


Cheers,

	Esben


-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Wednesday, January 16, 2008 10:01 AM
To: Esben Skovenborg
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] Double trouble

Hi Esben,

Esben Skovenborg <EsbenS at tcelectronic.com> writes:

> Now, I'm not sure if there's a better way of achieving this, or how to

> have different << operators for the xsd:double and xsd:decimal. 
> Perhaps the long double solution in XSD 2.3 was a pretty good idea
after all?

The problem with long double is that its support and size varies from
compiler to compiler and from platform to platform. As a result, several
compilers issued warning in that regard.

One way to solve the problem you've mentioned above without changing the
libxsd runtime would be to re-map (using type customization) xsd:double
to some other type, for example long double and to provide custom
parsing/serialization code which will use scientific notation.
I can elaborate on how to do this if you are interested in this
approach.

An even better solution would be to re-map xsd:decimal to long double
and somehow change parsing and serialization code for xsd:double to use
scientific notation. This is not possible right now because the
parsing/serialization code for fundamental types is always included into
the generated code even if the type was customized. This can be fixed by
splitting the parsing/serialization code into separate files for each
fundamental type and including them individually only when the
corresponding type is not customized. This way you will be able to
re-map xsd:double to double and xsd:decimal to long double and to
provide your own parsing and serialization code for these types. If you
are interested, we can implement this and build you a pre-release
binary.

Boris