I am trying to parse an ADL file using the ADLParser API. However, the ADLParser is throwing up an error in the ADL file that Im passing it. The block of code where the error occurs is :
------------
ELEMENT[at0008] occurrences matches {0..1} matches { -- Person
value matches {
TEXT matches {
value matches {"Patient", "Relative"}
}
}
}
-----------
and the line with the error is ------ value matches {"Patient", "Relative"}----. The compile time error thrown is
A string constraint can be expressed either by a fixed string or a regular expression. If you want to limit the string value to either "Patient" or "Relative", the correct syntax should be as following:
value matches {/Patient|Relative/}
The syntax in which the {"Patient", "Relative"} appears in the ADL file is probably the result of me selecting the "Free text or coded" option in the Entry model of the archetype editor. I havent manually written the values in this format so theres no way I can change it to look like this {/Patient|Relative/}.
The Editor version Im working with is 0.99.2 Beta. Im not sure if theres been any later release in which changes have been made with the ADL syntax.
The syntax for allowable text string values in the .Net parser and Tom’s I believe is a set of delimited strings as you have described. There is no use of regular expressions here at the moment. I am not sure of the latest developments in the parser but this is how it is in all current archetypes used by Ocean.
The syntax for allowable text string values in the .Net parser and Tom's I believe is a set of delimited strings as you have described. There is no use of regular expressions here at the moment. I am not sure of the latest developments in the parser but this is how it is in all current archetypes used by Ocean.
Sam
to help, see the attached archetype - it includes all the parsable constraints for basic types. Both {"list", "of", "strings"} and {/list|of|strings|/} are supported in ADL and in the reference parser (trying downloading the workbench from http://my.openehr.org/wsvn/oe_distrib/windows/adl_workbench/?rev=0&sc=0 - you can double check what the reference parser does).
Does this mean that changes will be required in the implementation of the specifications ?
to help, see the attached archetype - it includes all the parsable constraints for basic types. Both {"list", "of", "strings"} and {/list|of|strings|/} are supported in ADL and in the reference parser (trying downloading the workbench from http://my.openehr.org/wsvn/oe_distrib/windows/adl_workbench/?rev=0&sc=0 - you can double check what the reference parser does).
Does this mean that changes will be required in the implementation of the specifications ?
to help, see the attached archetype - it includes all the parsable constraints for basic types. Both {"list", "of", "strings"} and {/list|of|strings|/} are supported in ADL and in the reference parser (trying downloading the workbench from http://my.openehr.org/wsvn/oe_distrib/windows/adl_workbench/?rev=0&sc=0 - you can double check what the reference parser does).
Does this mean that changes will be required in the implementation of the specifications ?
not sure what you mean here Rahil???
Oh I meant whether the ADLParser will be modified to be able to deal with values demarcated with commas such as the problem I presented initially viz. value matches {"Patient", "Relative"}. At the moment a all to the parse( ) method on an ADL file with values stored as comma-delimited, results in a compile-time error and all my processing of the file ends there. If the parser can deal with comma-delimited values my file will parse properly.
Rong mentioned something about the ADL specification, which is why I wanted to know if the parser functionality might have to be changed so that such an error does not occur.
Hope Ive been a bit more clear. I think Rong might want to give his comments on this as well.
Rong mentioned something about the ADL specification, which is why I wanted to know if the parser functionality might have to be changed so that such an error does not occur.
There is some mismatch between the test description of String constraint and the syntax specification in the ADL spec document.
Since the Java parser is mostly based on the syntax specification, the support for string list within c_string is already there; but not properly tested - the order of sub rules needs to be adjusted. Now it's fixed in the subversion repository.
There is some mismatch between the test description of String constraint and the syntax specification in the ADL spec document.
Since the Java parser is mostly based on the syntax specification, the support for string list within c_string is already there; but not properly tested - the order of sub rules needs to be adjusted. Now it's fixed in the subversion repository.
Thats great. I had a look at the subversion repository. Where can I download the latest adl-parser jar file from? I had downloaded the earlier version from http://www.acode.se/frameset.jsp?cat=4&subcat=2&lang=en but cant see the latest version up there. Also, have changes been made to the openEHR kernel as well which might need a fresh download of its latest version as well?
Thats great. I had a look at the subversion repository. Where can I download the latest adl-parser jar file from? I had downloaded the earlier version from http://www.acode.se/frameset.jsp?cat=4&subcat=2&lang=en but cant see the latest version up there. Also, have changes been made to the openEHR kernel as well which might need a fresh download of its latest version as well?
There is some mismatch between the test description of String constraint and the syntax specification in the ADL spec document.
Since the Java parser is mostly based on the syntax specification, the support for string list within c_string is already there; but not properly tested - the order of sub rules needs to be adjusted. Now it's fixed in the subversion repository.
Thats great. I had a look at the subversion repository. Where can I download the latest adl-parser jar file from? I had downloaded the earlier version from http://www.acode.se/frameset.jsp?cat=4&subcat=2&lang=en but cant see the latest version up there. Also, have changes been made to the openEHR kernel as well which might need a fresh download of its latest version as well?
The adl-parser jar has just been updated on Acode release page.