Fwd: From JDiveLog to Subsurface

[Linus Torvalds]

This whole discussion got dropped from the list at some point, I'm
just putting it back in public so that other people know what is being
discussed.

                   Linus

---------- Forwarded message ----------
From: Linus Torvalds <torvalds at linux-foundation.org>
Date: Tue, Nov 1, 2011 at 9:42 AM
Subject: Re: From JDiveLog to Subsurface
To: Miika Turkia <miika.turkia at gmail.com>


On Tue, Nov 1, 2011 at 9:24 AM, Miika Turkia <miika.turkia at gmail.com> wrote:
>
> I was actually thinking about import feature for people to move from other
> dive log software to subsurface and implement that import using the libxslt.
> And if it would make any sense if I tried to hack together such import
> feature.

I do think that as an "import" feature, it's probably a good idea.

I wouldn't mind getting rid of the C code to import UDDF (it's a very
weak importer anyway), suunto and divinglog format xml (the
libdivecomputer "example" xml we can probably just drop entirely - we
import it because I had been playing around with libdivecomputer
stand-alone for a longish time, but I doubt anybody else has, and the
native support for libdivecomputer means that the example xml import
is kind of pointless).

Using xslt to convert those to the native subsurface format probably
isn't a bad idea.

> That is so true. I did notice when writing the xslt for jdivelog that the
> math is quite wrong in xslt (I've been told it is the same also e.g. with
> python). But then again when working with already rounded data I do not know
> how bad such inaccuracies with the conversions would be. (Again talking
> about importing existing dive logs from e.g. JDiveLog and SDM.)

Yes. Suunto SDM in particular seems to really like actively changing
the dive information - rounding timestamps, smoothing sample depths
etc.

Subsurface actively tries to avoid changing sample information - when
we plot things, we convert the samples into a specific plot structure
in order to then change things *there* instead (eg the multi-tank
thing needs to update tank pressures etc).

We do drop redundant information, though (eg consecutive temperature
samples with the same temperature etc). And we do convert things into
sane units, of course, and the conversion can certainly get some
least-significant-bit rounding effects etc (which is why subsurface
internally uses extra precision that doesn't make much sense:
milli-bar etc. We may not go all the way to "femto-meters", but there
is certainly *some* extraneous precision as a buffer for doing
conversion from PSI to BAR and back, and getting the same visible
values).

So not having perfect math in the conversion is certainly fine. The
real problem is figuring out what the proper unit is - and I don't at
all guarantee that our C importer gets it right either. For exmaple,
DivingLog seems to give sample pressures in PSI but the start/end
cylinder pressures in bar - and I suspect that the "sample pressure in
PSI" actually depends on some other unit setting field. It's just that
the only test-case I tried had it in PSI - so we get it right for
*that* particular setting of DivingLog, but we might be getting it
wrong for *other* DivingLog save-files.

Getting things like that right is always going to be a matter of
random hacks, and whether you use xslt or C won't much matter. I don't
know how general-purpose xslt conversions can be, but I assume they
can set flags depending on random other xml fields and then do
conditional unit conversions based on those flags if required?

Anyway, in the end it really boils down to me not particularly liking
generic XML, or necessarily wanting to learn about xslt. I tried very
hard to make the subsurface XML not be "just XML", but also be actual
human-readable text that could also be parsed *without* necessarily
needing to have a real XML parser for it. And I think that is
important, exactly to counter-act the kinds of crap that XML *allows*
people to do (and so many xml users clearly do do).

So if you want to do the xslt rules to convert Suunto SDM files, for
example, I would certainly not object. I'll happily remove the suunto
hacks from our current xml parser.

                 Linus