This question is in some sense a follow up to #31.
Both before and after that issue was fixed, XML.jl seemed to have made the deliberate choice not to escape existing escape sequences like & and <, etc a second time.
This is inconsistent with the behaviour of EzXML.
I don't have an opinion on which is right (if either) or even which is better. However, I have recently been challenged to clarify the difference as it manifests itself in XLSX.jl.
Specifically, it was previously possible to create a cell value of &; & " < > ' when XLSX.jl relied on EzXML. That is no longer possible. While EzXML escaped the value to &; &amp; &quot; &lt; &gt; &apos; , so the cell value was preserved as specified, XML.jl passes through the already escaped values with the result that the cell value becomes & & " < > '.
This is not a common use case (to say the least!) so I'd be happy to say this change in XLSX.jl is simply a reflection of the different behaviour of XML.jl, but I wonder if there is more to this that I could say. Are there any plans to change the behaviour of XML.jl in this respect (note: I am not asking for change)?
This question is in some sense a follow up to #31.
Both before and after that issue was fixed, XML.jl seemed to have made the deliberate choice not to escape existing escape sequences like
&and<, etc a second time.This is inconsistent with the behaviour of EzXML.
I don't have an opinion on which is right (if either) or even which is better. However, I have recently been challenged to clarify the difference as it manifests itself in XLSX.jl.
Specifically, it was previously possible to create a cell value of
&; & " < > 'when XLSX.jl relied on EzXML. That is no longer possible. While EzXML escaped the value to&; &amp; &quot; &lt; &gt; &apos;, so the cell value was preserved as specified, XML.jl passes through the already escaped values with the result that the cell value becomes& & " < > '.This is not a common use case (to say the least!) so I'd be happy to say this change in XLSX.jl is simply a reflection of the different behaviour of XML.jl, but I wonder if there is more to this that I could say. Are there any plans to change the behaviour of XML.jl in this respect (note: I am not asking for change)?