updated versions of archetype specs

Implementers (archive)
1

Dear all,

the ADL, ADL2, AOM and oAP specifications have all been updated with most, but not quite all changes on the todo list - many resulting from feedback on this list. You can find them in the usual place (the 1.0.1 branch - http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html).

Change log:
Major upgrade to ADL and oAP documents, including:

  • split grammar to correspond to ADL and oAP specifications
  • added explanation of ac codes - section 5.3.9
  • removed sections of ADL2 document that duplicate ADL1.x
  • added section on encoding and character quoting - section 3
  • other small text improvements

I am interested in feedback on the encoding section I added to the ADL document, as well as on anything else.

thanks,

  • thomas
2

- added explanation of ac codes - section 5.3.9
- added section on encoding and character quoting - section 3

I am interested in feedback on the encoding section I added to the ADL
document, as well as on anything else.

the ac and encoding sections both read fine to me.

For the encoding, there's no \uxxxx syntax included?
I realise that by supporting UTF-8 you don't absolutely
need it, but similar to the provision of \t, \n - it may allow
construction of adl in editors that aren't quite up to
UTF-8..

Also, it maybe should state that use of \ with an
invalid character after it (i.e. \q) is illegal and not to
be interpreted as the literal characters \ then q.

Andrew

3

Hi Thomas,

Just had a quick look on the updated versions and found the following:

  1. Grammar for translation part of the archetype is still missing (p99 the of ADL spec).
  2. I found new grammar section for c_code_phrase and c_ordinal, but they are not very detailed. For instance, there is no mentioning of assumed value in the grammar.
  3. I couldn’t find any example for asssumed value in c_quantity. Is it not supported (because of using inline dADL format?). Will there be any custom syntax for c_quantity?

Regards,
Rong

4

Andrew Patterson wrote:

the ac and encoding sections both read fine to me.

For the encoding, there's no \uxxxx syntax included?
I realise that by supporting UTF-8 you don't absolutely
need it, but similar to the provision of \t, \n - it may allow
construction of adl in editors that aren't quite up to
UTF-8..
  

I debated about it with myself...I just wonder if we put it in as a part
of the base specification it means software builders have to support it,
even though it may never be used... On the other hand, it is easy to
specify - I would be tempted to specify it as optional, but the only
allowed way to use ascii character quoting (as opposed to the XML & ISO
stuff we had before); and say that if it appears to be required in the
future we will make it mandatory.

thoughts on this?

Also, it maybe should state that use of \ with an
invalid character after it (i.e. \q) is illegal and not to
be interpreted as the literal characters \ then q.
  

good point.

- thomas

5

Rong Chen wrote:

Hi Thomas,

Just had a quick look on the updated versions and found the following:

1. Grammar for translation part of the archetype is still missing (p99
the of ADL spec).

fixed

2. I found new grammar section for c_code_phrase and c_ordinal, but
they are not very detailed. For instance, there is no mentioning of
assumed value in the grammar.

See the items marked ******* ASSUMED VALUE ******** below...

c_object:
  c_complex_object

archetype_internal_ref
archetype_slot
constraint_ref
c_code_phrase -- added
c_ordinal -- added
c_primitive_object
V_C_DOMAIN_TYPE
ERR_C_DOMAIN_TYPE
error

c_ordinal:
  c_ordinal_spec

c_ordinal_spec ; integer_value ********** ASSUMED VALUE **********
c_ordinal_spec ; error

c_ordinal_spec:
  ordinal

c_ordinal_spec , ordinal

ordinal:
  integer_value SYM_INTERVAL_DELIM V_QUALIFIED_TERM_CODE_REF

c_code_phrase:
  V_TERM_CODE_CONSTRAINT

V_QUALIFIED_TERM_CODE_REF

Symbols
The following patterns are added to the lexical specification for the standard cADL grammar.

---------/* V_TERM_CODE_CONSTRAINT of form */ -----------------------
-- [terminology_id::code, -- comment
-- code, -- comment
-- code] -- comment