[PATCH] Fix GPS import from divinglog

[Dirk Hohndel]

Linus Torvalds <torvalds at linux-foundation.org> writes:

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

I end up doing that at times as well when responding from my tablet or
phone... Aquamail allows me to answer inline, but it is usually too much
of a pain to do so.

> 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.

Completely agree. I don't want to tighten it down "too much". I want to
make it easier to maintain. And more robust to parse our own format. 
I'll comment more below.

> 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.

Yep

> 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.

Yes. I like the fact that it gives us flexibility. But the mass of
different keywords that we support for other formats, the different
number formats, the heuristics for what units might be in use... all
those things that were NEVER part of our file format - I believe that
the parser could be shorter and easier to maintain if we cut these out
and instead handle them in XSLT.

> 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.

Yes - that is exactly along the same lines: right now we don't look at
the units because most of the other formats don't have them. And I
actually worry if the change we added for the percentages may not subtly
break one of the other formats that we support.

So I'd like for us to be more consistent in checking things for OUR
format - and push the conversions needed to allow us to parse OTHER
formats into XSLT.

/D


> 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

-- 
Dirk Hohndel
Intel Open Source Technology Center