Although the latest spec defines that the DvDuration
has attributes such as days, hours etc the class lacks
the attribute years.
On the other hand, the draft XML Schema definition of
DvDuration (element DV_DURATION of BaseTypes.xsd),
defines the value of DvDuration as "xsd:duration",
which supports the notion of years.
In my opinion, this inconsistency may result to
ambiguous mapping of DV_DURATION element to DvDuration
class, and I propose to either restrict the definition
of DV_DURATION (to not accept years) or extend the
definition of DvDuration (introduction of years
attribute).
Additionally, the java reference implementation of
DvDuration class (rev 28), has a factory method -
getInstance(String): DvDuration - that accepts a
string formatted according ISO8601. The method uses a
pattern to verify the provided string. I believe that
this pattern should follow the suggestion of ISO861 of
using the capital letter T, in the case where both
days and time are representing in the same string.
Because the XML Schema "xsd:duration" uses the capital
letter T, this minor change will make more
straightforward the mapping of DvDuration to XML.
These are all good suggestions, and in fact we have become aware that the Date/time classes are not properly ISO8601 compliant. The 'T' problem has been fixed in the specifications, and the extended version of the Duration will be supported.
I have a more radical proposal as well: to scrap the PARTIAL_XX classes, and retain only DV_DATE, DV_TIME, DV_DATE_TIME and DV_DURATION. The partial semantics would be moved into these remaining 4 classes qite easily, and the nice thing about ISO8601 is it supports the partialness (reduced accuracy they call it) in exactly the way we want. So the result would be 4 classes that exactly implement ISO8601, while providing a standardised functional interface to dates and times in the EHR.
We have already re-implemented the Java openEHR date/time classes using the joda libraries (http://joda-time.sourceforge.net/). These upgraded classes are part of the Release 1.0 upgrade of the openEHR Java classes, which should be uploaded to subversion soon and will be announced.
I totaly agree with you that the standalone versions
of partial date/time classes are nearly useless.
This becomes obvious when you try to map the XML
schema element DV_DATE_TIME to a RM object.
I have another java - xml suggestion.
At runtime, due to the way generics are implemented in
java ("erasure"), there is no way to know the class of
T in a generic.
If I am not wrong this leads to the following problem:
You cannot map a DvInterval<T> instance to one of the
XS_DV_INTERVAL_XXX elements, although the reverse
mapping is easy.
I totaly agree with you that the standalone versions
of partial date/time classes are nearly useless.
This becomes obvious when you try to map the XML
schema element DV_DATE_TIME to a RM object.
I have another java - xml suggestion. At runtime, due to the way generics are implemented in
java ("erasure"), there is no way to know the class of
T in a generic.
If I am not wrong this leads to the following problem:
You cannot map a DvInterval<T> instance to one of the
XS_DV_INTERVAL_XXX elements, although the reverse
mapping is easy.