[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] help with orphan-control in xsl-fo
From: |
Greg Chicares |
Subject: |
Re: [lmi] help with orphan-control in xsl-fo |
Date: |
Wed, 20 Jul 2016 21:24:12 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 |
On 2016-07-20 15:45, Vadim Zeitlin wrote:
> On Wed, 20 Jul 2016 14:30:08 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> But I see another anomaly: with current libxslt, xsltwrapp says only:
> GC> runtime error: file C:/opt/lmi/lmi-MID-20160729Z/reg_d_individual.xsl
> GC> line 598 element param
> GC> without the extra line
> GC> Unexpected XSLT element 'param'
> GC> that we see with xsltproc. That extra line is desirable; is there a way
> GC> to have it included in the exception that libxslt throws?
>
> Libxslt does return the error to us, the trouble is that it actually
> returns 6 of them (for 3 different errors) but xsltwrapp by default throws
> an exception whenever the first one is processed, so the rest of them are
> lost.
It's a Goldilocks problem. One line isn't enough, because it's only half
of a message. But all lines would be too much if libxslt prints dozens or
thousands of errors--cf. this discussion:
http://lists.nongnu.org/archive/html/lmi/2013-04/msg00000.html
| Right now, we see only the first schema-failure message. Would the new error-
| reporting API let us display all of them? (I'm not sure we'd want to show them
| all, because they might be very lengthy, though it would be interesting to
try.
| The most important thing is to know whether validation succeeded; if it
failed,
| we can always get a complete report by applying the schema manually.)
One full error message (both halves of the first) would be just right.
The real problem is that libxslt provides six half-messages instead of
three full messages; xsltwrapp can't fix that.
> In the light of this example, I do wonder if this is the right thing
> to do and, in fact, I think it isn't and that xsltwrapp should throw an
> exception with the combined error message by default -- and let people who
> need individual errors define their own error handler classes.
If you make that change, then it would be useful (if libxslt allows it)
to have a setting (or an argument) to halt XSL processing immediately
on the first error (so that end users never see a messagebox with a
thousand errors).
> But luckily xsltwrapp is already flexible enough to let us do it ourselves
> and with the following patch:
Yes, thanks, but--back to the Goldilocks analysis--I'd rather that
end users see half of one error message than some potentially
unlimited number. And I'd rather write one easy-to-read line:
> - os << z.apply(d.document());
than many:
> + xml::document result;
> + xml::error_messages errors;
> + if(!z.apply(d.document(), result, errors))
> + {
> + throw xml::exception(errors.print());
> + }
> + os << result;
...to which I'd then want to add extra code to limit the number of
diagnostics. It's just not worth it. Sorry, I wouldn't even have
asked if I had realized that libxslt is issuing diagnostics as a
stream of text rather than as distinct units.