Dear Heath, The problem I?m focusing is an incorrectness regarding the dual model methodology rules.
If in a reference model we have an attribute of the type ?String?, an archetype constraining it must be a C_String instance from the archetype model. If we had an attribute of the type ?Date?, then the correct AOM class to constraint it would be a C_Date. The problem here is that in the reference model we have a ?String? attribute (the ?value? attribute of the DV_DATE) but the generated archetypes use a C_Date class to constraint it instead using a C_String. Here is the mismatch. Following the principles of the dual model approach we cannot consider that a valid archetype with regard to the underlying reference model. 2009/11/16 Heath Frankel <heath.frankel at oceaninformatics.com> > 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:* openehr-technical-bounces at openehr.org [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) > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- 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/d2a2197d/attachment.html>
