Problem with ADL Parser and unusual order in translation details

Dear Rong, Thomas, and all

The Java ADL Parser seems to expect that a translation details are always in a given order…

For example the following will lead to a parser error because the parser expects language instead of author first:

language
	original_language = <[ISO_639-1::en]>
	translations = <
		["de"] = <
			author = <
				["organisation"] = <"Central Queensland University, University of Heidelberg">
				["name"] = <"Sebastian Garde, Jasmin Buck">
			>
			language = <[ISO_639-1::de]>
		>
	>

According to:

http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140013989006_972489_4893Report.html

I think there should be no mandated order, however the relevant part from the Java Parser seems to mandate that the language is always first:

Map<String, TranslationDetails> translations() :
{
Token t;
String langAsKey;
CodePhrase language;
TranslationDetails td;
Map<String, TranslationDetails> map = new HashMap<String, TranslationDetails>();
Map<String, String> author;
String accreditation = null;
Map<String, String> otherDetails = null;
}
{
(
<SYM_L_BRACKET> langAsKey = string_value() <SYM_R_BRACKET> <SYM_EQ> <SYM_LT>
`<SYM_LANG_LANGUAGE> <SYM_EQ> "<" language = code_phrase() ">"` `<SYM_AUTHOR> <SYM_EQ> <SYM_LT>` `author = string_string_map()` `<SYM_GT>`
[
<SYM_ACCREDITATION> <SYM_EQ> <SYM_LT>
accreditation = string_value()
<SYM_GT>
]
``
[
<SYM_LANG_OTHER_DETAILS> <SYM_EQ> <SYM_LT>
otherDetails = string_string_map()
<SYM_GT>
]
<SYM_GT>
{
// TODO null terminology service
td = new TranslationDetails(language, author, accreditation,
otherDetails, null);
map.put(langAsKey, td);
}
)+
{ return map; }
}

This problem has occurred when Heather generated a new archetype with the latest internal release of the ocean archetype editor which for whatever reason now sorts author before language.
If I understand the specs right the Editor’s behaviour is ok - even if the old way was more readable in a way - and the Java parser needs to accommodate this.

Cheers
Sebastian

There is no mandated order, that is correct - an archetype with the
parts of the description section in any order, but otherwise correct
should parse. This is not to say of course that a preferred order should
not be used for display, serialising etc, since it improves readability.

- thomas

Sebastian Garde wrote:

Thanks for reporting the issue. It’s now fixed in the version on the TRUNK.

Cheers,
Rong