Hi Heath
We have addressed this issue in ADL and the Archetype Editor already. The
decision appears to be strongly for using the 'Invariant culture' in the
Java and .Net environments. It does mean setting the thread of the
serialisation to this invariant culture.
Cheers, Sam
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: Thursday, 29 January 2009 3:22 PM
To: 'For openEHR technical discussions'
Cc: 'For openEHR implementation discussions'
Subject: International representation of decimal magnitude in DV_QUANTITY
Hi all,
Our.NET implementation of the openEHR RM DV_QUANTITY is dependent on the
regional setting on the system, for example a magnitude of 1.0 on a system
with 'en' regional settings will be represented as 1,0 on a system with 'de'
regional settings.
Thilo has recently identified an issue where our serialisation of these RM
objects when in the 'de' culture produces an XML instance of DV_QUNATITY as
follows:
value xsi:type=DV_QUANTITY
magnitude1,2/magnitude
unitsmm/units
/value
When validated against the openEHR XML schema, this is not valid because
DV_QUANTITY.magnitude is declared as type=xs:double.
We can resolve this issue in our implementation, but the question is if
openEHR wants to support DV_QUANTITY.magnitude representations containing a
comma.
The openEHR data types specifications indicates that assumes built-in
primitive types such as Character, Boolean, Integer and Double based on ISO
11404 within an implementation environment such as Java, .NET. and XML.
This was the rational of using the xs:double type in the openEHR XML Schema
for DV_QUANTITY.magnitude.
Having said that, the openEHR XML schema has implemented its own ISO8601_x
assumed Date/Time types because the built-in XML Schema DateTime type does
not support the openEHR assumed ISO8601 capability of partial date/time, nor
the separate Date and Time types. The ISO8601_x types implemented in the
openEHR XML Schema does support both period (.) and comma (,) for fractional
seconds.
I have spoken to Tom about this and we feel that openEHR has two options:
1) Update the XML Schema to implement an culture aware double type to
be used in DV_QUANTITY.magnitude. This change would not invalidate any
existing data instances but would make instances based on that new schema
invalid against previous revisions.
2) Leave the XML Schema as is and make culture-aware serialisation and
rending responsible for converting the representation of
DV_QUNATITY.magnitude into the local cultures representation.
Can anyone suggest another option?
It is Thomas and my preference for option 2.
Are there anyone from the regions that use the comma representation of
decimal points that feel that option 1 is necessary?
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
ph: +61 (0)8 8223 3075
mb: +61 (0)412 030 741
email: heath.frankel at oceaninformatics.com
mailto:heath.frankel at oceaninformatics.biz
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090202/b5362b22/attachment.html
