Re: Transformations and location reporting

Hello Norm and group,

In my experience the confusion here is temporary -- and the problem is not
only in XProc -- while I am also doubtful that adding complexity to the
reporting will help. It does seem to me (on the general topic) that a
validator of any kind that can report paths, not just line/offsets, is
going to be useful in pipelines for reasons that are obvious, or become
obvious as one learns.

My vote would be to do nothing except explain/document that line numbers
are sometimes ... artifacts of prior handling or of (unseen, upstream)
provenance? Could the problem be mitigated by 'decorating' with additional
locators?

Cheers, Wendell



On Wed, Mar 18, 2026 at 8:12 AM Norm Tovey-Walsh <ndw@nwalsh.com> wrote:

> Hello,
>
> A recent bug report has highlighted an interesting challenge in managing
> XProc steps. Consider this transformation:
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="3.0">
> <xsl:template match="/">
>   <doc/>
> </xsl:template>
> </xsl:stylesheet>
>
> The resulting document is “<doc/>” irrespective of the input (that’s not
> really a critical part of the issue, it’s just a simplification for this
> example). What is the location of that element node? One plausible answer
> (the answer that XML Calabash reports) is line 4, column 9. That’s the
> location of the literal result element in the stylesheet. That’s the only
> plausible answer that XSLT *can* give since the location of the element in
> the stylesheet is all it knows.
>
> But if you pass the transformation result document to a validation step
> that says “doc” isn’t valid, the reported location: line 4, column 9, is
> likely to be confusing.
>
> The first thought you might have is that the XSLT step should “renumber”
> the locations. And it could plausibly do that, but not without having to
> make some decision about how many lines and columns an element start tag
> occupies. If you actually serialize the document, then the number of lines
> and columns an element start tag occupies is highly dependent on the
> serialization options used in the serialization, so there isn’t a “right”
> answer!
>
> As a pipeline author, I think the only way you can assure that you get
> accurate location information is if you parse the document from some
> serialization. If you want to transform then validate, and you want the
> error locations to be correct, you have to manage a p:store/p:load pair of
> steps and you have to understand that the reported error location will
> depend on the p:store serialization and not necessarily on any “original”
> version.
>
> That’s unfortunate, but I don’t see any way around it.
>
> For the p:xslt step, I think there are two possibilities for an
> implementation: it can discard the line and column information so that they
> don’t appear in any validation report, which avoids confusion, or it can
> leave the locations alone, which may be confusing, but is sometimes correct
> and useful.
>
> (I suppose the p:xslt step *could* serialize and reparse the results, but
> that would potentially be very expensive and the user wouldn’t necessarily
> have access to the intermediate serialized form, so there’s no guarantee
> that the resulting line and column numbers wouldn’t be wrong with respect
> to whatever serialization they have available. So it seems like a very bad
> option.)
>
> I really don’t know what’s is best.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh <ndw@nwalsh.com>
> https://norm.tovey-walsh.com/
>
> > The reason lightning doesn't strike twice in the same place is that the
> same place isn't there the second time.--Willie Tyler
>
>

-- 
...Wendell Piez... ...wendellpiez.com...
...pellucidliterature.org... ...pausepress.org... ...github.com/wendellpiez.
..