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 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Source code formatting, Michael Kay mike@xxx | Thread | Re: [xsl] Source code formatting, Michele R Combs mrro |
Re: [xsl] Source code formatting, Michael Kay mike@xxx | Date | Re: [xsl] Source code formatting, Michele R Combs mrro |
Month |