XML attributes escaping seems to be broken

[mykola-mokhnach]

It looks like attributes parsing has been broken in some previous xmldom versions. I'm not sure which one, but here are the details:

import xmldom from '@xmldom/xmldom';

let srcTree = `<?xml version="1.0" encoding="UTF-8"?>
  <element attribute="&lt;&gt;&quot;&amp;"/>
`;

let parser = new xmldom.DOMParser();

let tree = parser.parseFromString(srcTree);

let doc = parser.parseFromString(`<?xml version="1.0" encoding="UTF-8"?><root/>`);
doc.documentElement.appendChild(tree.documentElement);

console.log(new xmldom.XMLSerializer().serializeToString(doc));

The expected output here would be <?xml version="1.0" encoding="UTF-8"?><root><element attribute="&lt;&gt;&quot;&amp;"/></root>, but the current recent module version (0.7.5) outputs
<?xml version="1.0" encoding="UTF-8"?><root><element attribute="&lt;>&quot;&amp;"/></root>, e.g.
the > character does not get escaped properly while it is prohibited to use in attribute values according to the XML spec.

[mykola-mokhnach]

Probably related to #198

[karfau]

Thank you for reporting it, but this is a duplicate of #58.

There are some issues with your report though:

1. I checked past versions of xmldom with your code, including all deprecated versions that the new maintainers feel responsible for: https://stackblitz.com/edit/js-saacme?file=index.js
   (to see the output you need to expand the console on the bottom right)
   And didn't find a single version in which xmldom serialized > as >.

Just to be extra sure, I also additionally log the value of the attribute after parsing which of course always contains the > as expected, so it's a pure serialization issue, not a parsing issue.

2. I'm not aware of any XML spec that forbids > in attribute values. As I said before:

Just some details about why I didn't also add escaping for >:

According to the specs I linked in the PR #199, the < not being part of attribute values is a well-formedness constraint (so it's not about validity of the XML).
But this is not true for > in attribute values, or at least I couldn't find anything about it.

Here are those links again:

• https://www.w3.org/TR/xml11/#CleanAttrVals
• https://www.w3.org/TR/xml11/#NT-AttValue

If you know of any other spec that indicates the limitation you are describing, please provide a link to it.

[mykola-mokhnach]

Thank you for the quick response @karfau

What I could read in the specification that you've attached is:

The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.

xmllib2 and other serializers are doing that escaping for ">" character (if you know any lib that does not then please let me know). I was just wondering then what is the reason this library should be different from them?

[karfau]

Here is how I understand the specs, piece by piece:

The right angle bracket (>) may be represented using the string ">",

not a must, but allowed

and must, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, [and] when that string is not marking the end of a CDATA section.

(empahsis mine) Only when it is part of content and preceded by ]] and not marking the end of a CDATA section it has to be escaped.
This part is taken care of by xmldom since 0.5.0.

Why is xmldom not doing it like other libaries?
Because "it" didn't have a high enough priority for us so far.
And "it" not just being to convert > in the different places, but in general taking care of "How and to what degree can users of xmldom control what characters should be escaped during serialization?" => If you want to contribute to that discussion (beyond talking about >), please add your ideas/comments to #58

[mykola-mokhnach]

Sure, thanks for the detailed explanation.