Quoting Grahame Grieve <grahame at kestral.com.au>: > > No. A good standard should ensure that all implementations that satisfy it > are > > mutually interoperable (see, for example, the Whitworth stanard for nuts > and > > bolts!). > > should it? I'm not so sure that this is the correct definition of a good > standard. > While I certainly see it's appeal, it seems to me that there's a tension > between > interoperable and flexible, and the business managers - the people that > actually > spend money on systems - do not wish to have systems that are fully locked > down. > In this sense, standards that lock things down are not what is desired, and > the > standards need to search for a happy medium.
If compliance to a standard does not guarantee interoperabilty with everything alse that complies to the standard, then what exactly is being standardised? > > > This requires that: > > 1. the standard include the the tests that supposdly conformant > implementation > > must pass; > > 2. that test be necessary and sufficent to guarantee compliance; and > > 3. Proven compliance to the standard be necessary and sufficient to > guarantee > > interoperability. > > Out of idle interest, would you care to nominate an IT interoperability > standard > that actually meets your criteria? That's not an idle question. Merely asking it reveals serious problems that have plagued the IT industry for over half a century, re programming languages, operating systems, comms protocols, office applications, databases, etc. etc. These problems arise mainly through the industry's failure to address these three criteria, which necessarily introduce concepts of formal definition and proof that have been beyond the capability, and even comprehension, of most IT systems suppliers and their customers. > > > One way to do this is to for the standard to overdetermine implementation > to > > such an extent that exactly one implementation satisfy it. This is how 'de > > facto standards' work. > > I don't agree with that either. In fact, if only one implementation can > satisfy > it, it's not an interoperability standard. > On the contrary. A standard that's defined by an implementation guarantees interoperability among the users of that implementation. That's how MS won its market share. > As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move > things along, and contribute to the overall picture, instead of whining > about such trivia as version management. Of course the problem he describes > is painful, but this problem is not new, nor specific to HL7. > > Other HL7 naysayers have gone and done something useful at least; that's why > we're on this list. (though, strictly, the doing something useful came first. > That's why I've stopped bothering to read Barry Smith) > > > But I was of the impression that that was not the intention of the > international > > health care community. > > in as much as such a diverse group can be said to have an intention, it > wanders > somewhere between cheap, flexible, and interoperable. But you can only have > two > of those three. Can you demonstrate that these three properties are necessarily mutually incompatible? And, if it is indeed so, which of them would you advocate prioritising in the domain of healthcare? > > Grahame > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- __ Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. London EC1V 0HB tel: ++44-20-7040-8448 fax: ++44-20-7040-8587 b.cohen at city.ac.uk WWW: http://www.soi.city.ac.uk/~bernie "Patterns lively of the things rehearsed" ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
