Re: [xsl] Source code formatting

Subject: Re: [xsl] Source code formatting
From: "Willem Van Lishout willemvanlishout@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 30 Jul 2020 08:06:44 -0000
Thanks everyone.
What I did is monkey patch Xerces to skip the normalization for attributes.
I still end up with &#10; instead of actual carriage returns, but it seems
I can fix that in XSLT by using a character map.
In my research I found out that the .NET XmlTextReader class allows
disabling normalization:
https://docs.microsoft.com/en-us/dotnet/api/system.xml.xmltextreader.normalization?view=netcore-3.1
, perhaps it's useful to somebody...

Willem Van Lishout
willemvanlishout@xxxxxxxxx



On Wed, Jul 29, 2020 at 1:20 PM Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Agreed, the attribute normalization spec is an absolute pain, and being
> able to switch it off would have many benefits and no adverse consequences
> I can foresee.
>
> Michael Kay
> Saxonica
>
> On 29 Jul 2020, at 09:27, Pieter Lamers pieter.lamers@xxxxxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I have the same problem when storing XSLT documents in eXist-db. Attribute
> normalization also kills whitespace there because the spec says whitespace
> should be ignored in attribute values (and eXist-db normalizes against the
> spec). Isn't it about time to change the spec in this respect?
>
> Pieter
> On 28/07/2020 23:18, 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
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/2854576> (by
> email)
>
> --
> Pieter Lamers
> John Benjamins Publishing Company
> Postal Address: P.O. Box 36224, 1020 ME AMSTERDAM, The Netherlands
> Visiting Address: Klaprozenweg 75G, 1033 NN AMSTERDAM, The Netherlands
> Warehouse: Kelvinstraat 11-13, 1446 TK PURMEREND, The Netherlands
> tel: +31 20 630 4747
> web: www.benjamins.com
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
> email)
>
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3166594> (by
> email <>)

Current Thread