Re: [xsl] Source code formatting

["Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

I recently thought about this when I wondered how we can preserve 
whitespace in attributes when migrating XProc 1.0 documents (that often 
include inline XSLT with multi-line attributes, in addition to their own 
multiline attributes) to XProc 3.0.

At first I thought that the easiest solution would be to patch xerces so 
that it optionally doesnbt perform whitespace normalization in 
attributes any more.

But for migrating XProc it might be useful to parse the XPath 
expressions anyway, because they sometimes need to be modified in a 
non-trivial way. And once you parse them, you can reformat them. 
Possibly not at the original locations, but after iteration 2 it will be 
idempotent. And thatbs what you probably want, an XPath linter within 
your XSLT linter.

People I know of who recently parsed XPath 3.1 (with XSLT and probably 
also other languages, maybe with REx-generated parsers) are Wendell Piez 
and Phil Fearon. Maybe they can point you to a readily available 
REx-generated parser in XSLT.

A poor man's solution could be to use string-based preprocessing (be it 
unparsed-text() from within XSLT, Perl, ...) in order to substitute 
whitespace in the attributes with other characters (maybe from the 
private use area), lint the XSLT, and then revert the replacements.

Gerrit




On 28.07.2020 23:17, Willem Van Lishout willemvanlishout@xxxxxxxxx wrote:
> Hi list,
>
> Like many of you, I assume, I use a version control system when working 
> on XSLT projects. I'm working together with multiple people, and we run 
> the code through an XML formatter before checking it in to avoid 
> formatting differences showing up in the diffs.
>
> The problem is that, due to attribute value normalization, carriage 
> returns are removed from attribute nodes during XML parsing. When using 
> long XPath expressions (and this has become very common in XSLT 3, 
> especially with higher order functions), which are split in multiple 
> lines, this results in huge single line outputs which are impossible to 
> read.
>
> It seems any sort of XML processing will irreversibly transform the 
> whitespace, therefore I have to choose between:
> - No formatting
> - Formatting using non-XML tools?
> - Finding a parser that bends the rules...
>
> Have any of you experienced the same problem and did you find a solution?
>
> Thanks.
>
> Willem Van Lishout
> willemvanlishout@xxxxxxxxx <mailto:willemvanlishout@xxxxxxxxx>
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/225679> 
> (by email <>)