Adam, If binary standards have dried up then why is W3C producing the Efficient XML Interchange http://www.w3.org/XML/EXI/? There is also ISO standard based on ASN.1 (http://asn1.elibel.tm.fr/xml/finf.htm) that also produces a binary encoding of XML. Perhaps there is a need to reduce XML document size?
Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Adam Flinton > Sent: Friday, 18 April 2008 11:21 PM > To: timothywayne.cook at gmail.com; For openEHR technical discussions > Subject: Re: On Information and Interoperability > > Tim Cook wrote: > > Hi Adam, > > > > On Fri, 2008-04-18 at 11:55 +0100, Adam Flinton wrote: > > > >> > >> Stepping outside of well supported standards increases maintenance > >> requirements much much more. > >> > >> > > > > Well, I am not certain I would say much much more but in any case there > > are reasons why new standards are developed. > > > > > Oh indeed however there are some givens wrt stds etc: > > A) Binary stds (esp "on the wire") stds have died off (CORBA, COM etc) & > formatted text has taken off as a result of the plethora of langauges & > uses. I used to be a big OpenDoc/SOM person & then I used to like RMI > etc but....test messaging is a more "survivable" approach when people > look at systems with long shelf lives (which is esp the case in terms of > things like the CFH program). > > Like Python.....OK this will work with it....Perl? OK......C++? > OK....etc.etc. > > Being able to read a text file/stream is just about the lowest common > denominator wrt inter-systems comms. > > B) wrt XML the std mark up of an element <> </> etc & attributes as > basically properties/ini format of x="y" is so std now (esp wrt the > prevalence of HTML) that I can not see much shifting that. > Wrt actual low level designs etc within that sphere (W3C Schema vs Relax > or XSLTv1 vs V2 etc) & then the higher level (e.g. HL7 Mif or XMI or SVG > etc) will be subject to change & the strady growth in new standards. The > recent ODF/OOXML fight is an example of this. > > >> Heck why not write your ADL handling etc in PICK ? > >> You might find it hard to get Dell et all to support Pick on your choice > >> of hardware so why not try & build your own hardware with Pick optimised > >> chips while you're at it? > >> > >> > > > > I assume you meant to surround this with sarcasm tags. > > > > > Only just. Once you start down the "roll your own" route where do you stop? > > >> If you want to write your very own persistence mechanism/db I cannot but > >> admire your ambition but I would caution wrt expecting others wishing to > >> use it vs spending a bit more on hardware. > >> > >> > > > > This wasn't the subject. I used the SQL database use as an analogy. I > > don't need to create my own (even if I could) object databases prove > > themselves very useful in implementation. > > > > > See above. > > > >>> How this applies to healthcare is that healthcare information must > >>> contain truth. That truth is fully dependent on the complete context of > >>> where, when and how it was recorded. This context needs to be > >>> understood in all spatial and temporal instances where this information > >>> is or may need to be used. > >>> > > > > > >> An obvious response would be that Heisenberg would argue with the above. > >> > > > > Well, I am not a quantum physicist and would not argue with him in that > > domain of course. However, a lot has changed in information processing > > since he passed away in 1976. I would venture to guess that he might > > have made some adjustments to his uncertainty principle in the process. > > > > There is certainly a great deal of vagueness in healthcare information > > and the ARB has had MANY discussions about handling these situations. > > But I still maintain that vagueness nor uncertainty negates the expected > > truth value of healthcare information. The truth of healthcare > > information exists in the context of which it is collected. It may > > later proved to be incorrect but if the complete context of the > > information is known, it will be understood by the receiver. > > > > An interesting subject indeed but we are drifting off the subject to > > some extent. :-) > > > > > > <G> > > > >> However the whole point of an object model (as opposed to an object > >> implementation) is that it is implementation neutral. > >> > >> > > > > True. But the implementation must faithfully represent the semantics of > > the model or it isn't an implementation. > > > > > No argument from me. However to take the example of UML (& please note I > am not a great fan of UML as it is more of a "meta-standard" (try > taking a xmi/model from one "UML" tool to another....)) you can design > your class diagram etc & then persist/implement that model in all sorts > of ways. So long as you can faithfully re-create that model then...... > > e.g. A mate of mine called Bob has built this: > > http://umlspeed.sourceforge.net/ > > Which I often use for quick modelling. > > As an example from the above, Were there an AOM/MOF mapping then in > theory you could persist an archetype out as XMI. > > BTW sidenote: I have looked at both a "MIF/MIF Mapping " (I like the > name if not the result <G>) & an AOM MOF. > > Dave Carlson of the VA has done much more on the HL7 part & that will > (hopefully) help towards the creation of a consistent MOF/EMF model for > HL7 wrt doing our eclipse tooling. > > I will raise this as a different thread. > >> "As part of its commitment to OHT, NHS Connecting for Health has > >> contributed an XML processing engine" > >> > > > > > > I look forward to your work be proven in implementations. I think it > > COULD be wonderful to use XML. > > > > > It could indeed. > > >> > >>> [NOTE] You will also need to address the issues that Thomas Beale just > >>> presented, in the referenced thread, regarding the real world as well. > >>> > >>> > >>> > >> I have done so. > >> > > > > I agree with your format vs. design comments there. But, your examples > > lead me to believe that you are still focusing on sending messages with > > limited context and have not considered implications regarding storage > > and retrieval of healthcare information for decision support, public > > health analysis, etc. > > > > > oh don't go there......I have had months of fun wrt the above & do not > wish to revisit that. I will say in summary that if one were to keep all > info & to wish to retrieve that then it would be unworkable & that the > reality is that it's a matter of working out what to keep & what to > discard period irrespective of language etc. > > > I look forward to continued to discussions/education on your XML > > progress. > > > > Now back to our regularly scheduled work! ;-) > > > > > OK > > Adam > > ********************************************************************** > This message may contain confidential and privileged information. > If you are not the intended recipient please accept our apologies. > Please do not disclose, copy or distribute information in this e-mail > or take any action in reliance on its contents: to do so is strictly > prohibited and may be unlawful. Please inform us that this message has > gone astray before deleting it. Thank you for your co-operation. > > NHSmail is used daily by over 100,000 staff in the NHS. Over a million > messages are sent every day by the system. To find out why more and > more NHS personnel are switching to this NHS Connecting for Health > system please visit www.connectingforhealth.nhs.uk/nhsmail > ********************************************************************** > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
