Thomas, The new file didn't get out; it was replaced with:
This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "openEHR-EHR-OBSERVATION.visual.new.adl" is on the list of unacceptable attachments for this site and has been replaced by this warning message. If you wish to receive a copy of the original attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Sat Jun 4 17:26:49 2005 the virus scanner said: MailScanner: Attempt to hide real filename extension (openEHR-EHR-OBSERVATION.visual.new.adl) Note to Help Desk: Look on the CHIME (inetsrv-1) MailScanner in /var/spool/MailScanner/quarantine/20050604 (message j54GQjiS016770). -- System Admin CHIME, Royal Free & University Collge Medical School E-Mail: sysadmin at chime.ucl.ac.uk David. ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: "Openehr-Technical" <openehr-technical at openehr.org>; <openehr-clinical at openehr.org> Sent: Sunday, June 05, 2005 2:26 AM Subject: {Filename?} Proposed major change to ADL archetype syntax > Warning: This message has had one or more attachments removed > (openEHR-EHR-OBSERVATION.visual.new.adl). Please read the > "CHIME-Attachment-Warning.txt" attachment(s) for more information. > > > > Dear all, > > as part of the ongoing work with archetypes in the openEHR community it > has become clear that a change to the syntax would be desirable. The > change is essentially to convert ADL archetypes from their somewhat > idiosyncratic syntax to being regular dADL documents. The semantics would > not change, but it would mean that parsers and serialisers could > mechanically convert between ADL documents and AOM instance trees. "ADL" > would thus cease to be a special syntax, and would instead denote dADL > documents whose filenames end in ".adl" (note that I am likely to propose > that the names of the subsyntaxes dADL and cADL change in the future as > well). > > These changes would have a number of benefits. Firstly, it would mean that > parsing an ADL file is just parsing a dADL document, where one of the > field types happens to be the curly-bracket syntax currently known as > cADL. Since dADL is completely mappable to XML (in fact it is a completely > regular abstract syntax for well-formed XML), the change will facilitate > XML serialisation and deserialisation of archetypes. > > It will even be possible in the future to use 100% dADL throughout the > archetype, since the cADL section can be serialised as dADL syntax, > although it will of course lose its readability as a constraint syntax. > This kind of serialisation is what could be used as the first step to XML > serialisation, and also coming from XML. (If this paragraph does not make > sense to you now, don't worry!) > > Some detailed changes would then be possible in the archetype document > structure, to make it match up properly with the Archetype Object Model; > mainly to do with the top sections, the language sections (currently in > the ontology section); and the revision history section. > > Overall, this change will make ADL archetypes processible with simpler > software, and easier to process in and out of XML. It will also align it > to other syntaxes similar in nature to dADL, such as YATL. > > What we would like to know is: > > a.. general reactions to this proposed change > b.. how soon people would be prepared to have the change implemented. By > preference, we would implemented it in the documents and archetypes tools > within the next 8 weeks. > c.. whether there are enough archetypes already in existence to justify > making a conversion tool, or whether people would be happy to make the > changes by hand. These would admittedly be annoying, but it would allow us > to upgrade the software faster, since we would not need the backward > compatibility features. > To give a feel for the change, two archetypes are attached to this mail: > one in today's syntax, and one in the proposed syntax. > > Clearly it would have been nicer if we had worked this out in the > beginning, but that is the nature of research: what is clear now has only > been arrived at by experimenting with the initial creation. My expectation > is that after this change, there will be very few changes required to the > syntax indeed; those that are required (e.g. due to a new attribute in a > class in the AOM) will have minimal impact on the software, since they > will be processible with an already established syntax. > > Lastly, human authors of archetypes do not have much to worry about: they > will see only minor changes to the tools (e.g. due to the adjustment to > the language and translation sections of archetypes), and should otherwise > not notice any difference. > > - thomas beale > > > -- > ___________________________________________________________________________________ > CTO Ocean Informatics (http://www.OceanInformatics.biz) > Research Fellow, University College London (http://www.chime.ucl.ac.uk) > Chair Architectural Review Board, openEHR (http://www.openEHR.org) > -------------------------------------------------------------------------------- > archetype > openEHR-EHR-OBSERVATION.visual.v1 > > concept > [at0000] -- Visual observation > > description > original_author = < > ["name"] = <"Sam Heard"> > ["organisation"] = <"Ocean Informatics"> > ["date"] = <"2004-05-18"> > > > lifecycle_state = <"draft"> > details = < > ["en"] = < > language = <"en"> > purpose = <"visual acuity observation"> > keywords = <"visual", "eye", "opthalmology"> > copyright = <"copyright (c) 2004 Ocean Informatics"> > > > > > > definition > OBSERVATION[at0000] matches { -- Visual observation > data matches { > HISTORY[at0002] matches { -- history > events cardinality matches {1..*; ordered} matches { > EVENT[at0003] occurrences matches {0..*} matches { -- Any event > data matches { > TREE[at0001] matches { -- structure > items cardinality matches {0..1; ordered} matches { > CLUSTER[at0008] occurrences matches {1..*} matches { -- Object and > findings > items cardinality matches {0..1; ordered} matches { > ELEMENT[at0009] matches { -- Finding site > value matches { > CODED_TEXT matches { > code matches {[ac0001]} -- =any body part including the whole > } > } > } > ELEMENT[at0010] occurrences matches {0..1} matches { -- Finding site > description > value matches { > TEXT matches {*} > } > } > } > } > CLUSTER[at0011] occurrences matches {0..1} matches { -- Findings > items cardinality matches {0..1; ordered} matches { > ELEMENT[at0013] occurrences matches {0..1} matches { -- Normal > value matches {True, False} > } > ELEMENT[at0014] occurrences matches {0..1} matches { -- Clinical findings > value matches { > TEXT matches {*} > } > } > } > } > } > } > } > } > } > } > } > } > > ontology > primary_language = <"en"> > languages_available = <"en", ...> > term_definitions = < > ["en"] = < > items = < > ["at0000"] = < > description = <"Allows recording of visual observations regarding any > aspect of the body, the surface features of the body, at endoscopy or by > radiology or other visualisation techniques"> > text = <"Visual observation"> > > > ["at0001"] = < > description = <"@ internal @"> > text = <"structure"> > > > ["at0002"] = < > description = <"@ internal @"> > text = <"history"> > > > ["at0003"] = < > description = <"*"> > text = <"Any event"> > > > ["at0008"] = < > description = <"Grouping for the object and findings"> > text = <"Object and findings"> > > > ["at0009"] = < > description = <"*"> > text = <"Finding site"> > > > ["at0010"] = < > description = <"A textural description of the body site"> > text = <"Finding site description"> > > > ["at0011"] = < > description = <"*"> > text = <"Findings"> > > > ["at0013"] = < > description = <"Are the findings normal"> > text = <"Normal"> > > > ["at0014"] = < > description = <"Description of the findings"> > text = <"Clinical findings"> > > > > > > > > > constraint_definitions = < > ["en"] = < > items = < > ["ac0001"] = < > description = <"Able to record the object of the visual observation"> > text = <"=any body part including the whole"> > > > > > > > > > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.1 - Release Date: 3/06/2005 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
