Re: [lmi] help with orphan-control in xsl-fo

[Greg Chicares]

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.