[Top][All Lists]
[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-----