Tom,
>> That's two!
>
> we have a different counting system in the antipodes;-)
So if I say you owe me 20 quid, does that mean you owe me 10, or owe me
30? :)
> all I would say there is that XML tags aren't there for humans to
> read. 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).
The point that XML can be unreadable is quite reasonable, but obviously
you can more-or-less obfuscate any chosen piece of syntax. The point of
my Java code example was to show that XML can be quite concise if you
don't start adding in namespaces and other clutter. Conversely, the
extract from the spec document that I included was to show that without
the comments, even the ADL examples in the document can be difficult to
follow.
In any case while the opinion is fair enough, the claim that my soul is
tortured might not be a matter of formal openEHR policy in a
specification 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.
Hmm, well I can clearly pick out things like what the Systolic values
are. But in any case this only proves that an HTML table isn't the best
native representation for a sequence of readings. In the second part of
the data structure I can see what the value of the
"contextConductionInd" is quite easily. It might be argued that I have
no idea what the contextConductionInd actually represents, and that's
true, but that's an issue of meaning, not of syntax.
> 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'm not sure about (a), but certainly (b) and (c) are completely valid
observations.
> 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.
Yacc and Lex provide only the tools to read a sequence of tokens from a
stream and form a parse tree. They do nothing to interpret that into
the meaning given by the information model that should underpin it
(they don't tell me what the contextConductionInd really was and why it
was important).
> 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.
Well as I suggested in my last mail, all things are relative. A piece
of Greek text is obviously human-readable, but it won't help me in the
slightest. I found ADL to be quite mathematical. Perhaps I simply
always need the visual tools.
> 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).
Absolutely. This is true of any information model.
> 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.
I certainly don't mean to imply that it is globally useless! But in
fairness, if I can't use it, it's useless to me, by definition. And if
parsing was easy, it would be easy to fix, correct?
> 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.
This is also a very important and worthwhile observation. Perhaps the
use of ADL is mandated because the other formalisms are deficient? That
would certainly be a compelling reason to pursue ADL. It would be
interesting to see what all the deficiencies are.
> 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.
Fair enough.
All the best,
Tony.
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
