fsfe-uk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Formats was Re: [Fsfe-uk] Gnu/Linux and freedom (was Linux in Thailand.)


From: Simon Waters
Subject: Formats was Re: [Fsfe-uk] Gnu/Linux and freedom (was Linux in Thailand.)
Date: Thu, 8 Jan 2004 20:53:36 +0000
User-agent: KMail/1.5.4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 07 January 2004 12:33 am, Chris Croughton wrote:
> On Tue, Jan 06, 2004 at 10:25:52PM +0000, Mark Preston wrote:
>
> > This may be a deliberate policy on the part of [CompanyB].

Most often there is no commercial imperative to allow your data to be imported 
by someone else in proprietary software - where as if your code is open 
system integrators may provide these export tools.

Similarly people can decipher you own import formats.

Format specifications are of course easy to do, but most IT companies don't 
employ people with experience of defining format data formats (XML may be 
helping here, but how many small IT companies have people intimately familiar 
with XML?). Best is a formal specification for the protocol, and a working 
open source implementation, although you always risk being told you've 
implemented your own protocol wrong - life's like that.

> I can safely buy a
> CAD/CAM package, for instance, knowing that it will at minimum input and
> output in the standard Gerber format.

CAD has obviously come a long way since I was supporting loads of CAD 
stations. We had dreadful import problems - despite Pro/Engineer supporting a 
whole load of third party formats. Leastwise our client still had skilled 
engineers digitising information from paper drawing - not often - these days 
paper drawing often aren't precise enough for critical components in engine 
manufacture aparently.

Medical record formats are a lot tougher than CAD, as exporting a CAD document 
you can lose all sorts of information as the relevant bits can usually be 
readily conveyed to the recipient in other forms - the part looks like this - 
but by the way we want it made from this alloy with these characteristics - 
send us a quote. This is because the part is well defined and you know in 
advance (at least roughly) what the recipient needs in terms of his role 
(manufacturer, fitter, etc).

Medical record exchanges typically mustn't lose information, and more 
importantly mustn't subtlely alter it. In the end this tends to come down to 
loosely structured pieces of information, such as extensive textual notes by 
the various medical professionals, image files (no changing the format from 
one to other and losing that vital detail). Additional to this are extensive 
agreed lists of terms, that denote conditions of interest. Of course this 
makes data mining for non-agree terms across diverse systems difficult.

Much as I think the NHS plan to produce one system is probably doomed - I 
certainly understand why they would prefer ONE system for GP records.

We all know that monopoly providers are rarely the best as they are not driven 
by competitive pressures, and that you end up with divergence within one 
system over time if only old and new versions.  
-----BEGIN PGP SIGNATURE-----
Comment: Encryption...is a powerful defensive weapon for free people.

iD8DBQE//cNQGFXfHI9FVgYRAnyBAJ9icCTRP+YbrbcAKnXA5dzCirdlYgCeK9Z6
6ENExrvdJHaPVf+0I73J800=
=qEEv
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]