0.8.4 should not have been a minor release

[valytica-mattb]

The security fix implemented in 0.8.4 caused breaking changes in production for us, and for anyone who relied on the previous behaviour in < 0.8.3 and should not have been a minor version change imo.

[karfau]

Thank for raising your voice @valytica-mattb .
As I noted in https://github.com/xmldom/xmldom/releases/tag/0.8.4 :

We consider it more important to align with the specs that we want to be aligned with, considering the potential security issues that might derive from people not being aware of the difference in behavior.

But I would really love to understand your use case and if there is a fix we can provide to support that use case.
Can you please provide more information of what exactly you are were doing that worked and stopped working? Ideally with some xml samples?

You can also contact us at security@xmldom.org if you prefer to have this conversation in a non public manner, or you can file a bug, and prepare a reproduction scenario in stackblitz (see issue template).

[valytica-mattb]

Thanks @karfau,

I completely understand that aligning with the spec is a valid enhancement to make, the issue is just that it was released as a semver patch upgrade, which are supposed to be backwards compatible and this change was not.

We were using xmldom to process very large multi-root xml files and split them into multiple single-root xml files by streaming the file in and progressively parsing it. Xmldom would allow us to identify when a complete root had been streamed in, and by using the 'unclosed xml attribute' warning we were able to split out the subsequent root(s). Not likely to be a common use case, but xmldom had been a robust solution for the last couple of years until this change was made.

[karfau]

As part of this fix we were considering that if the demand is high enough we might be willing to actually provide a way of doing that by providing a way to parse a "DocumentFragment" from a string.

This is nothing that any specification describes, but it could be implemented by using a newly invented mimeType as the second argument, which would lead to parseFromString not returning a Document but a DocumentFragment, which is allowed to have multiple elements.

It would of course add some complexity to the library and some support in implementing something like this would be highly appriciated.

But first we would need to see how many people have been relying on this way of parsing XML.

So please, if you have a similar use case, post it here (in which case I will be notified) or give a thumbs up (which doesn't notify me but still provides a matter of signaling what you think about such an idea (:+1: or :-1:).