Hi David, There is nothing wrong in the openEHR specifications or the Ocean Archetype Editor?s construction of the ADL representation of an ELEMENT of type DV_DATE.
The RM specifies the DV_DATE class as having a value attribute of type string that represents an ISO8601 date, which supports partial dates, e.g. ?1934-05? or ?1934? (also note that ?193405? is also a valid ISO8601 representation of ?1934-05?). These partial dates are not supported by XML?s xs:date and hence it has not been used in the schema. The constraint specified in the ADL fragment you have provided below is a further constraint on this ISO8601 representation, as specified in http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf section 5.4.6.1. This particular constraint indicates that the month is optional and day is not to be provided, so valid date must be a partial date like the examples above. What Java Parser are you using? Are you sure that the parser is not producing a DvDate object that represents the value attribute of the ELEMENT, which itself has a value attribute which has a constrained string representation of a partial date? Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel at oceaninformatics.com +61 (0) 8 7127 5574 From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner Sent: Friday, 13 November 2009 9:09 PM To: For openEHR technical discussions Subject: DV_DATE definition mismatch Hello everybody, I have detected what it seems a mismatch between the DV_DATE definition of the reference model and the ADL parser/AOM model specifications. At the RM, the DV_DATE value is defined as a String constrained as an ISO8601 pattern. This is both at the RM specification and at the XML Schema. Following the ADL/AOM specifications, something such as (this code has been generated by the Ocean Archetype Editor) DV_DATE matches { value matches {yyyy-??-XX} } will be parsed as a C_Primitive_Object of the type Date (in fact, DvDate at the java parser that I use). The problem then is that the DvDate type parsed does not correspond to the String definition of the RM, generating then a non valid archetype that does not correspond to the RM. There are two possible solutions. Or the RM is changed to represent correctly the DV_DATE value as a "xs:date" type with the appropriate ISO8601 facet or the archetypes should take the form value matches {"yyyy-??-XX"} to be parsed as a String according to the RM definition. I'm right with this? -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091116/f6e54fd3/attachment.html>
