I only just noticed this post from a few months ago..... the problem highlighted by David is a slight anomaly in the modelling, because the concrete type of DV_DATE is indeed a String, but one whose pattern is constrained to be an ISO8601 Date. We constrain it with a C_DATE which should technically constrain some object of 'DATE' type. In teh ADL 1.5 spec this has been corrected so that C_DATE is defined explicitly as a constrainer for ISO8601_DATE. I realise the types do not quite match up, and this is because of the anomaly of a) using a strinng to represent a proper type - which is what ISO8601 does, and is also convenient since a String is easier to manage than some structured type b) but treating itas if it were a proper type.
Getting around this would require making the ISO8601_DATE types etc direct subtypes of the String class, which is not a particularly desirable thing to do. In the ADL 1.5 Archetype workbench, I have a substitution table for String/ISO8601 types, to deal with this anomaly. - thomas beale On 16/11/2009 10:01, David Moner wrote: > 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 > <mailto: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 > <mailto:heath.frankel at oceaninformatics.com> > > +61 (0) 8 7127 5574 > > *From:* openehr-technical-bounces at openehr.org > <mailto:openehr-technical-bounces at openehr.org> > [mailto: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 <mailto: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) > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100215/280617f2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100215/280617f2/attachment.jpg>
