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@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?
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@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@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
