# CR for the XML Schema definition and Java implementation of DvDuration

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2006-04-27 10:48 UTC
**Views:** 2
**Replies:** 4
**URL:** https://discourse.openehr.org/t/cr-for-the-xml-schema-definition-and-java-implementation-of-dvduration/14531

---

## Post #1 by @babisr

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

---

## Post #2 by @thomas.beale

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

Any further suggestions / thoughts welcome\.

\- thomas beale

babisr@yahoo\.com wrote:

---

## Post #3 by @babisr

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

So, I propose to augment the java implementation of
DvInterval class and add a method that returns the
class of T\. <a
href="http://javaton.blogspot.com/2006/04/java-generics-stay-away.html">Personaly
</a> I disagree with the use of java generics\.

\-\-\- Thomas Beale <Thomas\.Beale@OceanInformatics\.biz>
Ýãñáøå:

---

## Post #4 by @thomas.beale

babisr@yahoo\.com wrote:
> 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\.
>
> So, I propose to augment the java implementation of
> DvInterval class and add a method that returns the
> class of T\. <a
> href="http://javaton.blogspot.com/2006/04/java-generics-stay-away.html">Personaly
> </a> I disagree with the use of java generics\.
>  

I think this is because the design isn't very good \(which I agree \- it isn't\)\. Another reason to use Eiffel \(just kidding;\-\)

\- thomas

---

## Post #5 by @Sam

Heath Frankel is proposing a new type to allow the appropriate strings in the schema - I think this is a good idea.

Sam

---


**Canonical:** https://discourse.openehr.org/t/cr-for-the-xml-schema-definition-and-java-implementation-of-dvduration/14531
**Original content:** https://discourse.openehr.org/t/cr-for-the-xml-schema-definition-and-java-implementation-of-dvduration/14531