[PATCH] Flesh out the UDDF xml parsing a bit more

Dirk Hohndel dirk at hohndel.org
Fri Feb 22 20:22:32 PST 2013


Linus Torvalds <torvalds at linux-foundation.org> writes:
>
> Ugh. This part was the one that broke native format.
>
> The attached patch is a bit bigger, but that's largely because it adds
> that new helper function to parse floats and makes our old
> integer_or_float() (that doesn't return the required finishing part)
> use the new helper function. And the new helper function doesn't have
> that odd historical union thing).

This is so funny. When I read your patch I thought to myself "uh, this
will do bad things if we have percentages < 1, but hey, that never
happens in real life. I did forget that it also would fail for 1% - and
that both you and I have done fake trimix dives where we set the He% to
1.

Now granted, in real life that still is a rather unlikely value, but I
like this solution much better. Use the strength of our XML format to
our advantage.

Which brings up a different idea.

Given that we now have the beautiful, easy to read and understand XSLT
converters (...), should we consider making our parser a tiny bit less
promiscous? So have the XSLT do fairly clean conversions and throw
errors (or at least warnings) if non-Subsurface XML gets handed to the
parser? I think that would make our code overall more robust and would
make regressions less likely.

Because frankly - instead of having the parser be massaged to grok UDDF
it might be the better approach to have an XSLT stylesheet turn UDDF
into something sensible.

But this is intentionally phrased as a question as I am not 100% sure
what the right direction would be here.

/D


More information about the subsurface mailing list