[PATCH] Fix GPS import from divinglog

[Linus Torvalds]

(Sorry for the top-posting, I'm doing this on my nexus 7)

I agree that our parser is a bit to loose at times, but it actually has
lots of advantages even for our native format. Being so permissive in what
we accept is actually one reason we've been able to update our own format
easily. So I'd actually argue against tightening it up very much.

We've literally moved things around *completely* in or XML and didn't have
to worry about old XML files too much. Adding the dive computer section.
Moving things from outside of it to inside. Yadda yadda. That would have
been *much* more painful with a strict parser.

Yes, we've had bugs due to ambiguity, but we had a bug with the xslt
triggering when it shouldn't, too. So I'm not so convinced the loose
parsing is really all that horrid. I honestly think it's been much more of
a boon than a bane, _including_ vet much for our own native format.

The one way we could tighten things for ourselves is to do more of the
"actually look at the units" things, like we did for the percent sign. I'm
pretty sure there are other places where we look at the value to determine
what the unit is, for example.

           Linus
On Feb 25, 2013 7:23 AM, "Dirk Hohndel" <dirk at hohndel.org> wrote:

>
> On Feb 25, 2013, at 7:17 AM, Linus Torvalds wrote:
>
> > I'm not convinced xslt is any better. The language is so unreadable as
> to result in it being unmaintainable. I actually tried to write a stupid
> script to add ask the crazy XML syntax on top of something more readable,
> but I gave up.
> >
> > So the whole notion of having xml transformations for foreign formats is
> a nice idea, but it is destroyed my the horrible mess that is xslt.
>
> I agree that xslt has its shortcomings. But I'd rather have the
> preprocessing step and a sane parser than a parser that gets more and more
> promiscuous and has more and more subtle bugs that are a massive pain to
> track down.
>
> Miika is doing a great job maintaining our XSLT files - and I am slowly
> starting to wrap my mind around the insane syntax.
>
> So I repeat my statement. I'd really much rather have a tight parser for
> our format. And a preprocessing step that turns foreign formats into ours.
>
> Because overall, that is  much easier to keep running. Otherwise we find a
> bug in format X. We change the parser. Now we need to check that formats A,
> B, C, D, E - G are not broken by this.
> With the XSLT pre-processing we change the one XSLT style sheet - nothing
> else is affected.
>
> And the more we add formats (and I want to add all the formats we could
> possibly parse), the more convinced I am that this is the right step.
>
> /D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130225/71d8bb5b/attachment.html>