Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add XSLT linter #1490

Open
xworld21 opened this issue Mar 14, 2021 · 0 comments
Open

add XSLT linter #1490

xworld21 opened this issue Mar 14, 2021 · 0 comments

Comments

@xworld21
Copy link
Contributor

As per subject, I would like to add an XSLT linter, because I am manipulating the stylesheets with XSLT, and diff'ing the changes gets tricky with all the non-semantic differences caused by libxslt.

My idea would be to run the stylesheets through an (almost) identity XSLT transform, then postprocess the output to recover some of the original style:

  • convert literal newlines to &#x0A; inside <xsl:text>;
  • convert decimal character references to uppercase hexadecimal;
  • reinsert literal newlines inside the attribute values spanning several lines (the XML parser changes newlines into spaces, so one must use a hack here, e.g. restore newline + indentation whenever there is a string of consecutive spaces);
  • move the attributes of <xsl:stylesheet> and <xsl:output> to separate lines.

This can be done while keeping the stylesheets XML-equivalent to the original ones, down to the text nodes, although this means one cannot reindent tags. Things that are lost because of XML parsing:

  • how attributes and namespaces are laid out within each tag, except for <xsl:stylesheet> and <xsl:output> which are done manually from Perl;
  • you cannot use two or ore consecutive spaces inside an attribute value except for indentation; consecutive spaces are never needed, though, so that is a reasonable compromise, I hope;
  • you cannot use tabs within attributes, those are converted to spaces and cannot be recovered;
  • attributes that are intentionally within single quotes for readability, and there aren't any at the moment.

I have made a simple implementation in this branch. The linter croaks if the reformatted output is not equivalent to the original file, and it seems to work well.

How to read the branch: the pre-linter commits are minor adjustments that are supposed to have no consequence (of course, I submitted them as #1489, and they fail a test with TeXLive 2016, so that's not true! I'll investigate); the linter appears in a single commit; the final commit is how the files look like after linting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants