Below are some strings which return an exception in the parser, I would
appreciate if someone shortly comments on that.
(for readability I parted the email in "case 1" etc.)
Thanks
Bert Verhees
Below are some strings which return an exception in the parser, I would
appreciate if someone shortly comments on that.
(for readability I parted the email in "case 1" etc.)
Thanks
Bert Verhees
Below are some strings which return an exception in the parser, I would
appreciate if someone shortly comments on that.
(for readability I parted the email in “case 1” etc.)
Hi Bert,
Please find comments below. By the way, where did you find these ADL?
Cheers,
Rong
Thanks
Bert Verheescase 1
date_time_attr2 matches {yyyy-mm-ddThh:mm:??; 1995-03-17T12:01}
date_time_attr3 matches {yyyy-mm-ddThh:mm:XX; 1995-03-17T12:01}
The assumed value “1995-03-17T12:01” is not a valid datetime according to the spec.
– YYYY-MM-DDThh:mm:ss[,sss][Z|+/-nnnn]
se.acode.openehr.parser.ParseException : Encountered “1995-03-17” at line
409, column 95.
Was expecting one of:
<V_DATE_TIME> …
<V_DATE_TIME_MS> …
<V_DATE_TIME_Z> …
<V_DATE_TIME_MSZ> …case 2
DV_CODED_TEXT matches {
defining_code matches {
CODE_PHRASE matches {
terminology_id matches {“local”}
code_string matches
{“at15.0111”} <-------
}
}
}
Try to use the shorted form for code phrase, e.g. [openehr::431]
se.acode.openehr.parser.ParseException: Encountered “"at15.0111"” at
line 583, column 102.
Was expecting one of:
“}” …
“c_dv_quantity” …
<V_TYPE_IDENTIFIER> …
“use_node” …
<SYM_ALLOW_ARCHETYPE> …
<V_TERMINOLOGY_ID_BLOCK> …
<V_CODE_PHRASE> …
“+” …
“-” …
<V_INTEGER> …
“C_DV_ORDINAL” …
“true” …
“false” …
<V_ISO8601_DATE_CONSTRAINT_PATTERN> …
<V_DATE> …
“|” …
<V_ISO8601_TIME_CONSTRAINT_PATTERN> …
<V_HHMM_TIME> …
<V_HHMMSS_TIME> …
<V_HHMMSSss_TIME> …
<V_HHMMSSZ_TIME> …
<V_HHMMSSssZ_TIME> …
<V_ISO8601_DATE_TIME_CONSTRAINT_PATTERN> …
<V_DATE_TIME> …
<V_DATE_TIME_MS> …
<V_DATE_TIME_Z> …
<V_DATE_TIME_MSZ> …
<V_ISO8601_DURATION_CONSTRAINT_PATTERN> …
<V_ISO8601_DURATION> …
<V_STRING> …
<V_REGEXP> …
“*” …
<V_REAL> …
<V_LOCAL_TERM_CODE_REF> …
case 3
clinical_attr_3 matches {
C_CODE_PHRASE <}
se.acode.openehr.parser.ParseException: Encountered “>” at line 624,
column 57.
Was expecting:
<V_TYPE_IDENTIFIER> …
case 4
clinical_attr_4 matches {
C_CODE_PHRASE <
terminology_id = <
value = <“local”>}
Yes, support for these should probably be added to the parser. It will be easier once the dADL parser is separated from the main parser.
Thanks Rong for your reply, read my comments below
regards
Bert
Rong Chen schreef:
Below are some strings which return an exception in the parser, I would
appreciate if someone shortly comments on that.
(for readability I parted the email in "case 1" etc.)Hi Bert,
Please find comments below. By the way, where did you find these ADL?
This ADL is part of the knowledge-tree in the openehr-svn, you find it
somewhere under /dev/test/etc....
Cheers,
RongThanks
Bert Verhees
----------------------------------------------------------------------------------------
case 1
----------------------------------------------------------------------------------------date_time_attr2 matches {yyyy-mm-ddThh:mm:??; 1995-03-17T12:01}
date_time_attr3 matches {yyyy-mm-ddThh:mm:XX; 1995-03-17T12:01}The assumed value "1995-03-17T12:01" is not a valid datetime according
to the spec.
-- YYYY-MM-DDThh:mm:ss[,sss][Z|+/-nnnn]
Maybe I misunderstand, but I thought that ?? means "optional", and XX
means "not allowed", so the assumed values seem OK to me, but, maybe I
am wrong?
se.acode.openehr.parser.ParseException : Encountered "1995-03-17" at
line
409, column 95.
Was expecting one of:
<V_DATE_TIME> ...
<V_DATE_TIME_MS> ...
<V_DATE_TIME_Z> ...
<V_DATE_TIME_MSZ> ...
----------------------------------------------------------------------------------------
case 2
----------------------------------------------------------------------------------------
DV_CODED_TEXT matches {
defining_code matches {
CODE_PHRASE matches {
terminology_id matches {"local"}
code_string matches
{"at15.0111"} <-------
}
}
}Try to use the shorted form for code phrase, e.g. [openehr::431]
Thanks, I try tomorrow (other computer) I let you know. I think that is
the solution, but is this wrong? I mean do I need to support this construct?
se.acode.openehr.parser.ParseException: Encountered "\"at15.0111\"" at
line 583, column 102.
Was expecting one of:
"}" ...
"c_dv_quantity" ...
<V_TYPE_IDENTIFIER> ...
"use_node" ...
<SYM_ALLOW_ARCHETYPE> ...
<V_TERMINOLOGY_ID_BLOCK> ...
<V_CODE_PHRASE> ...
"+" ...
"-" ...
<V_INTEGER> ...
"C_DV_ORDINAL" ...
"true" ...
"false" ...
<V_ISO8601_DATE_CONSTRAINT_PATTERN> ...
<V_DATE> ...
"|" ...
<V_ISO8601_TIME_CONSTRAINT_PATTERN> ...
<V_HHMM_TIME> ...
<V_HHMMSS_TIME> ...
<V_HHMMSSss_TIME> ...
<V_HHMMSSZ_TIME> ...
<V_HHMMSSssZ_TIME> ...
<V_ISO8601_DATE_TIME_CONSTRAINT_PATTERN> ...
<V_DATE_TIME> ...
<V_DATE_TIME_MS> ...
<V_DATE_TIME_Z> ...
<V_DATE_TIME_MSZ> ...
<V_ISO8601_DURATION_CONSTRAINT_PATTERN> ...
<V_ISO8601_DURATION> ...
<V_STRING> ...
<V_REGEXP> ...
"*" ...
<V_REAL> ...
<V_LOCAL_TERM_CODE_REF> ...----------------------------------------------------------------------------------------
case 3
----------------------------------------------------------------------------------------clinical_attr_3 matches {
C_CODE_PHRASE <
>
}se.acode.openehr.parser.ParseException: Encountered ">" at line 624,
column 57.
Was expecting:
<V_TYPE_IDENTIFIER> ...----------------------------------------------------------------------------------------
case 4
----------------------------------------------------------------------------------------
clinical_attr_4 matches {
C_CODE_PHRASE <
terminology_id = <
value = <"local">
>
>
}Yes, support for these should probably be added to the parser. It will
be easier once the dADL parser is separated from the main parser.
It is OK for me to have this aknowledge, I can easily live with the fact
that it will be supported in the future, I work around it in the
meantime, is not really a problem, I think, for now.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Thanks Rong for your reply, read my comments below
regards
BertRong Chen schreef:
Below are some strings which return an exception in the parser, I would
appreciate if someone shortly comments on that.
(for readability I parted the email in “case 1” etc.)Hi Bert,
Please find comments below. By the way, where did you find these ADL?
This ADL is part of the knowledge-tree in the openehr-svn, you find it
somewhere under /dev/test/etc…
OK. Good to have some reference test ADL files.
Cheers,
RongThanks
Bert Verheescase 1
date_time_attr2 matches {yyyy-mm-ddThh:mm:??; 1995-03-17T12:01}
date_time_attr3 matches {yyyy-mm-ddThh:mm:XX; 1995-03-17T12:01}The assumed value “1995-03-17T12:01” is not a valid datetime according
to the spec.
– YYYY-MM-DDThh:mm:ss[,sss][Z|+/-nnnn]Maybe I misunderstand, but I thought that ?? means “optional”, and XX
means “not allowed”, so the assumed values seem OK to me, but, maybe I
am wrong?
Yes, you are right! I was too quick and just looked at the comment. Both the minutes and seconds can be optional according to the grammar. But the comment needs to be update since it looks like only millisecond isT optional.
se.acode.openehr.parser.ParseException : Encountered “1995-03-17” at
line
409, column 95.
Was expecting one of:
<V_DATE_TIME> …
<V_DATE_TIME_MS> …
<V_DATE_TIME_Z> …
<V_DATE_TIME_MSZ> …case 2
DV_CODED_TEXT matches {
defining_code matches {
CODE_PHRASE matches {
terminology_id matches {“local”}
code_string matches
{“at15.0111”} <-------
}
}
}Try to use the shorted form for code phrase, e.g. [openehr::431]
Thanks, I try tomorrow (other computer) I let you know. I think that is
the solution, but is this wrong? I mean do I need to support this construct?
Think so. The code_string could be fishy since the model needs just a plain string here but the value can be parsed as term_code.
se.acode.openehr.parser.ParseException: Encountered “"at15.0111"” at
line 583, column 102.
Was expecting one of:
“}” …
“c_dv_quantity” …
<V_TYPE_IDENTIFIER> …
“use_node” …
<SYM_ALLOW_ARCHETYPE> …
<V_TERMINOLOGY_ID_BLOCK> …
<V_CODE_PHRASE> …
“+” …
“-” …
<V_INTEGER> …
“C_DV_ORDINAL” …
“true” …
“false” …
<V_ISO8601_DATE_CONSTRAINT_PATTERN> …
<V_DATE> …
“|” …
<V_ISO8601_TIME_CONSTRAINT_PATTERN> …
<V_HHMM_TIME> …
<V_HHMMSS_TIME> …
<V_HHMMSSss_TIME> …
<V_HHMMSSZ_TIME> …
<V_HHMMSSssZ_TIME> …
<V_ISO8601_DATE_TIME_CONSTRAINT_PATTERN> …
<V_DATE_TIME> …
<V_DATE_TIME_MS> …
<V_DATE_TIME_Z> …
<V_DATE_TIME_MSZ> …
<V_ISO8601_DURATION_CONSTRAINT_PATTERN> …
<V_ISO8601_DURATION> …
<V_STRING> …
<V_REGEXP> …
“*” …
<V_REAL> …
<V_LOCAL_TERM_CODE_REF> …
case 3
clinical_attr_3 matches {
C_CODE_PHRASE <}
se.acode.openehr.parser.ParseException: Encountered “>” at line 624,
column 57.
Was expecting:
<V_TYPE_IDENTIFIER> …
case 4
clinical_attr_4 matches {
C_CODE_PHRASE <
terminology_id = <
value = <“local”>}
Yes, support for these should probably be added to the parser. It will
be easier once the dADL parser is separated from the main parser.It is OK for me to have this aknowledge, I can easily live with the fact
that it will be supported in the future, I work around it in the
meantime, is not really a problem, I think, for now.
Good to know. We already have support for empty C_DV_QUANTITY structure, so adding it should be fairly easy.
Cheers,
Rong