DV_DATE definition mismatch
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 {-??-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 {
DV_DATE definition mismatch
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-boun...@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 {-??-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 {-??-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
DV_DATE definition mismatch
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 {-??-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 {-??-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
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 {-??-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 {-??-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/20091113/7a6f71cf/attachment.html
DV_DATE definition mismatch
In a message dated 13-11-2009 12:22:04 W. Europe Standard Time,
damoca at gmail.com writes:
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 {-??-XX}
to be parsed as a String according to the RM definition.
shouldn't this be mmdd format
and why not the harmonized datatypes for electronic health records /
exchange according to ISO 21090? That is in particular developed for semantic
interoperability of data type formats and based on OpenEHR, CEN and HL7
examples.
It seems a bit silly to use another older standard for this.
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: Results4Care at cs.com
email: williamtfgoossen at cs.com
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091113/7552b9d6/attachment.html
DV_DATE definition mismatch
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091113/998daa9b/attachment.html
