While playing with ADL, I found myself collecting language rules in an app. I converted it to an editor. I hope you like: http://soysal.com/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 Please test it. I can continue development on interest.
And back to ADL discussion. First question here, who will use (e.i. learn) this language in a clinic requiring an additional archetype or modification? Next question, what will be the frequency of definition of a new archetype or modification in an health service? I believe, in majority of the cases, it may be impractical to expect some stuff to learn and remember this language. xml may have an advantage with html-like syntax. But the fact that, instead of manual coding these scripts, soon, there will be a heavy demand for a visual designer, string/term translator, and/or script generator wizards etc. In this case, you'll need to reverse engineer the ADL code back to load into the IDE :), sorry. So, a well defined, easily parsable format would be very beneficial in near future. Ergin > Tony Austin wrote: > >> XML will be one of the formats we can save to, but it is nearly >> useless when writing new syntaxes which you want to compute with. >> What XML is good at is only one thing really: platform independent >> machine representation and machine-to-machine communication. >> >> That's two! > > we have a different counting system in the antipodes;-) > >> For example, OWL has an abstract syntax - see >> http://www.w3.org/TR/owl-semantics/syntax.html - you might notice that >> raw RDF is nearly impossible for humans to read or think with. >> >> From http://www.w3.org/TR/owl-semantics/ it seems that the abstract >> syntaxes are used to restrict the possible expressions of OWL into >> smaller subsets. Full OWL has the same syntax as RDF: >> >> First, Section 2 contains a high-level, abstract syntax for >> both OWL Lite, a subset of OWL, and OWL DL, a fuller style of >> using OWL but one that still places some limitations on how >> OWL ontologies are constructed. Eliminating these limitations >> results in the full OWL language, called OWL Full, which has >> the same syntax as RDF. >> > not quite - have a look at for example some of the test cases: > http://www.w3.org/TR/owl-test/byFunction#function-FunctionalProperty - > this is raw RDF. I don't know how many people, if they're being honest > would say this is a readable syntax. There are some small examples of > the mapping of the abstract syntax to the concrete at > http://www.w3.org/TR/2002/WD-owl-semantics-20021108/examples.html. > >> >> >> I've removed the comments in the second extract. Now I'm not sure >> about anyone else, and it may have a lot to do with my not being >> especially mathematically minded, but I don't regard myself as a >> "tortured soul" (page 12 para 2) for having relatively less difficulty >> with the first than the second. And I think it could be parsed by a >> schema-reading XML parser? > > all I would say there is that XML tags aren't there for humans to read - > I have talked about this with a lot of people, and interestingly, at an > XML conference in Sydney last year heard a couple of the W3C core people > say more or less the same thing. Prof. Joachim Dudeck from Geissen > university in Germany always precedes the main part of any talk by a > statement to the effect "XML is not meant for humans - no-one should > ever read it, only machines". What I meant by 'tortured souls' was > simply that there is a widespread misunderstanding about XML in the IT > world - which is that, because you can open an XML file with a text > editor, it is somehow intended to be directly worked upon by humans; on > any non-trivial piece of XML, you do (in my opinion) have to be fairly > tortured to try and read it, rather than find a human-oriented > equivalent (which almost always exists). > > But I take your point, I hadn't actually realised that anyone might > compare the two syntax fragments in the light of this statement. In any > case, the OWL fragment should be replaced by a piece of abstract OWL. > >> >> We don't write in XML when writing in Java for example. >> >> >> I won't unduly labour the point but that is probably more to do with >> the compactness of the latter than the lack of human readability of >> the former: >> >> <package>org.openehr.a_package</package> >> <public><class>A_class<implements>Another_class</implements> >> >> vs. >> >> package org.openehr.a_package; >> public class A_class implements Another_class { ... > > well, that's one example where the syntaxes are somewhat close, but try > reading this (fragment of physical exam from CDA document): > ----------------------------------------------------------- > > <table> > > <tr> > > <th>*Date / Time*</th> > > <th>*April 7, 2000 14:30*</th> > > <th>*April 7, 2000 15:30*</th> > > </tr> > > <tr><th>*Height*</th><td>*177 cm (69.7 in)*</td></tr> > > <tr><th>*Weight*</th><td>*194.0 lbs (88.0 kg)*</td></tr> > > <tr><th>*BMI*</th><td>*28.1 kg/m2*</td></tr> > > <tr><th>*BSA*</th><td>*2.05 m2*</td></tr> > > <tr> > > <th>*Temperature*</th> > > <td>*36.9 C (98.5 F)*</td> > > <td>*36.9 C (98.5 F)*</td> > > </tr> > > <tr><th>*Pulse*</th><td>*86 / minute*</td><td>*84 / > minute*</td></tr> > > > <tr><th>*Rhythm*</th><td>*Regular*</td><td>*Regular*</td></tr> > > <tr> > > <th>*Respirations*</th> > > <td>*16 / minute, unlabored*</td> > > <td>*14 / minute*</td> > > </tr> > > <tr><th>*Systolic*</th><td>*132 mmHg*</td><td>*135 > mmHg*</td></tr> > > <tr><th>*Diastolic*</th><td>*86 mmHg*</td><td>*88 > mmHg*</td></tr> > > <tr><th>*Position / Cuff*</th><td>*Left > Arm*</td><td>*Left Arm*</td></tr> > > </table> > > </text> > > <component1> > > <typeCode code="*COMP*"/> > > <contextConductionInd value="*TRUE*"/> > > <cdaEntryObservation> > > <classCode code=???*OBS*???/> > > <moodCode code=???*EVN*???/> > > <code code=???*F-01851*??? codeSystem=???*SNOMED*??? > > displayName=???*Body height measure*???/> > > <effectiveTime value=???*200004071430*???/> > > <value xsi:type=???*PQ*??? value=???*1.77*??? > unit=???*m*???> > > <translation value=???*69.7*??? code=???*[in_I]*??? > codeSystem=???*UCUM*???/> > > </value> > > </cdaEntryObservation> > > </component1> > > <component1> > > > ----------------------------------------------------------- > > now, you can read it, sort of (it's a table), but it isn't at all > obvious what it means until you convert to a human consumable form, > which is of course what an XML browser will do to display it on the > screen. Now, go and compare a UML model with its XMI equivalent. You > have no hope of reading the latter, because not only are the XML tags > against you, but the classes and attributes are in different sections of > the text - good for machines, no use to humans. > > I would also say that if you go back to the programming language > example, you will find that almost all programming languages have a) > stronger semantics (e.g. ability to express functions, proper > inheritance), b) use of visual real-estate in the displayed text more or > less obeys the rule that visual area used corresponds to importance (it > never does in XML - it's mostly repeated tags you don't need to see), c) > the style of syntax is tailored to the kind of problem the language was > designed for. > > I have nothing against XML, for its intended purpose, but I do have a > big problem with the idea that humans should use it as a syntax for > thinking or reading. > >> >> After all, parsing is easy, >> >> >> I'm not sure that this is justified. Parsing is difficult. > > I would have to disagree there - it takes me about a day or two to build > a basic parser for any published language, given yacc/lex programming > tools & libraries. > >> As you well know, I still can't use your ADL parser and that is >> presently the only entr??e into the use of the language you have >> defined. Contrast this with the many parsers that Ergin Soysal alluded >> to. Writing a syntax is "easy" in the sense that you can sit down one >> day and dream one up, but that doesn't give it market credibility or >> widespread support. > > well, when the ADL XML-schema is published, all the XML-schema parsers > will be able to read it, and that's certainly an intended outcome. But > we couldn't have easily defined the semantics of ADL if we were limited > to something like XML-schema to do it - at least we would want UML. And > you still wouldn't be able to show someone a text of an archetype that > they could understand, where as an abstract syntax does have the > property of being explainable. But don't get me wrong - the XML stuff is > coming, it just takes a bit of time to get it all done. Also, don't > forget, the XML view of the world only gives you the data view; but > there is an API based on the functional part of the model behind ADL - > for this purpose, we still need to use programming languages (and/or > WSDL equivalents). > > I would like to defend the parser a bit - it's not totally useless: once > it has a Java interface, we will have covered the .Net and Java flavours > of the world, and for a lot of people, it is very useful to just re-use > such a component, benefitting from a growing, maintained, and widely > tested code base, just as for e.g. James Clark's original XML parser, > which gets wrapped into every language. The parser by the way will grow > to handle all the main XML formats. > >> >> Saving ADL as XML is easy, but then of course it is no longer >> readable in any meaningful way by humans, just by machines. >> >> >> In the version of the document I cited above there are a number of >> object models given (which I haven't had a chance to unpick yet). It >> might be contended that ADL is also only really readable by machines, >> given the highly mathematical nature of its format and at the least >> the enormity of a likely script. Now, given the object model, is there >> any longer a special need for ADL? > > well, there is a need for an interoperable, lossless representation of > archetypes. ADL is one possibility - it's text, which also happens to be > readable by (some) humans. If it turns out that the community prefers > another serialisation, e.g. XML-schema instance, OWL or YAML, for all I > care, then I have no problem whatsoever - ADL will then become a > primarily explanatory tool. But two things are worth pointing out: many > people do like to use abstract syntaxes (it's why math and music > notation exist...), and secondly, the experience so far with converting > archetypes to XML has had its problems - the DSTC has been doing it for > some years now, and you do get problems, mainly because XML-schema > cannot adequately represent everything in UML (its inheritance model is > broken, for a start), and you end up having to embed annotations to > avoid being lossy. But that's probably a detail. I have no personal > preference for what interoperable concrete syntax is chosen by industry, > or the community, only that it be able to represent the required > semantics properly. > >> Am I right that the stated purpose was to enable archetype development >> unencumbered by issues associated with additional syntax? Is not the >> object model now the necessary and sufficient condition to call that >> process "done"? > > I hadn't really thought about it in those terms I have to say. I have > received emails from people saying that they love using ADL, including > in fields outside of health; other people prefer to think in XML, or > UML, or functional interfaces - clearly the world is a diverse place. > The only claim I would make for ADL is that it precisely embodies a > conceptualisation of the problem and solution so that the problem can be > further thought about; I think some people and tools will continue to > use it, others won't. > >> Put another way, do you see an archetype repository as a persistence >> engine for objects of the sort given in the document, with ADL just >> one of a range of languages for inserting and retrieving archetypes? > > well, we need an archetype library (for collaborative authoring), > archetype servers (for runtime access in interoperable format) and in > some sites, local archetype repositories (for access to archetypes > converted to an efficient local form). > > In sum, ADL represents one entry point into the world of archetypes, > allowing its authors to develop other representations etc, which may be > more interesting than the original; I see this as a natural evolution > that occurs with any attempt to formalise an idea into computable form. > > > - thomas > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
