Introduction

The page is intended to provide helpful information to ADL parser developers.

TDD(Test Driven Development) is one of the most important concept for software engineering. Well described test cases are so called as "executable specification".

Because of the discrepancy between natural language and programming language, paper based specification documents cannot define the behavior of computer in detail.

To define computer language, BNF is popular method to describe its syntax to parse. ADL was also defined by BNF. However, in order to generate an archetype instance from ADL, it is necessarily to read parser implementation by Eiffel or Java reference implementation. There are subtle difference between Java implementation and Eiffel implementation. For example, the version segment of ARCHETYPE_ID is defined as DIGITAL in specification document and so is in Eiffel implementation, but Java implementation permits non-digital characters. Both Java and Eiffel implementation work well, but more concrete definition would be needed for ADL parser implementation.

To standardise parser implementation, writing test cases as executable specification would be better method than paper. I will write ADL parser behavior by Ruby RSpec2 from Eiffel and Java test cases.

Archetype meta data

Linked ADL file should be parsed as these semantics shown bellow:

ARCHETYPE_ID is "openEHR-EHR-SECTION-summary"
ADL VERSION is "1.4"
concept is at0000
original language is ISO_639-1::en
original_author' name is Sam Heard
original_author' organisation is Ocean Informatics
original_author' date is 9/01/2007

This behavior is described as this rspec file .

Archetype path

Archetype path test ADL should be parsed and construct paths shown bellow:

root path is "/"
wheels, the first attribute's path is "/wheels"
- first wheel is the first child of wheels' children
- first wheel's path is '/wheels[at0001]'
- first wheel's description path is '/wheels[at0001]/description'
- first wheel parts' path is '/wheels[at0001]/parts'
  - parts node is the first child of first wheel parts' children
  - parts node path is '/wheels[at0001]/parts[at0002]'
  - something of wheel parts is the first attribute of parts node
  - something of wheel parts node is '/wheels[at0001]/parts[at0002]/something'
  - something else of wheel parts is the second attribute of parts node
  - something else of wheel parts node is '/wheels[at0001]/parts[at0002]/something_else'
- second wheel is the second child of wheels' children
- second wheel path is '/wheels[at0003]'
- second wheel path description is '/wheels[at0003]/description'
- second wheel parts path is '/wheels[at0003]/parts'

This behavior is described as this RSpec file .

---- ----

The idea is to create a set of test ADL archetypes that can be used as common test fixtures for ADL parser implementions in any platform (Effiel, Java, Ruby, Python, C#.. you name it).

The benefit of having a common set of test archetypes is obvious. In order to achieve EHR interoperability using archetypes, we must in the first place achieve great interoperabilty between our ADL parsers ;-) and a platform-independent, common set of test archetypes can definitely help us there. The test suits work executable specification documents for reference. The test suits work executable specification documents for reference.

Currently the largest sets of test archetypes can be found in the reference Effiel implementation as well as the Java project. Ideally, these two sets of archetypes should be merged in the future. Note that all test archetypes in the Java project are in ADL 1.4, whiles the set from Effiel implementation has test archetypes in the latest ADL 1.5. Perhaps it makes sense for the community to aim for a unified common set of test archetypes starting by adopting the ADL 1.5 archetypes from Effiel project.

(following text is from Thomas Beale as part of off-list communication regarding test archetypes, quoted with permission)

the ADL 1.5 files are here , If you look at one of these archetypes, e.g. this one, you see that it is documented in a certain way, and that in the other_details section there is a 'regression' entry that contains the error code it will generate with the ADL Workbench reference compiler. If you run the reference compiler in test mode, with regression on, you see this kind of thing. See here for help on the ADL workbench.

These tests are I think mostly compatible with ADL 1.4 as well it is just that they are not specified in the ADL 1.4 specs. Some of the tests would have different results in ADL 1.4. One of the key differences is that you need your validator to have access to the reference model to do some of the checking.

ADL 1.5 sample archetypes for validity test
- ADL workbench
ADL 1.4 sample archetypes for validity test
- Eiffel
- Java