Replace the XML SAX parser with a DOM parser about imscjs

[gkatsev]

xmldom is only one suggestion. Any other suitable project is fine. This would likely involve creating two build outputs. One to be used by browsers and one by node.
For example, with mpd-parser, we import xmldom https://github.com/videojs/mpd-parser/blob/56eee17cfbdfbbbdb03c443776b4033405c5448a/src/stringToMpdXml.js#L1

import {DOMParser} from '@xmldom/xmldom';

And in the rollup config, for the "globals" build, we have @xmldom/xmldom return window https://github.com/videojs/mpd-parser/blob/56eee17cfbdfbbbdb03c443776b4033405c5448a/scripts/rollup.config.js#L36

    defaults.browser['@xmldom/xmldom'] = 'window';

Unless we wanted to do dynamic code loading, there's probably no way to handle this without multiple builds.

[palemieux]

I am fine with multiple builds.

[bbert]

@dsilhavy any opinion?
If it can reduce the bundle size, it can help, even if sax minified bundle is quite small.

FYI, in dash.js the metadataHandler in fromXML() is used: https://github.com/Dash-Industry-Forum/dash.js/blob/54612bb541c43cb7ce900f0c49111999ff817ae2/src/streaming/utils/TTMLParser.js#L130

[gkatsev]

The sax parser is almost a 3rd of the minified-gzipped size of this project (checked via bundlephobia.com).

In another project, I've used https://github.com/xmldom/xmldom for doing the parsing in node and then in the bundle for browsers, it rewrites the import to be return window, since xmldom returns an object with a DOMParser property on it.

While I do think that worrying about a few kb here and there isn't a big deal when you're going to be streaming large video files, it's still helpful to reduce filesize when and where we can, particularly for code that ships to the client side. This seems like a good candidate to help reduce the bundled size of the project.

[nigelmegitt]

@nigelmegitt any strong feelings?

From the documentation for xmldom:

xmldom has an own SAX parser implementation to do the actual parsing

I suspect that changing sax.js for xmldom would likely increase the parsing duration and the minified size, though I haven't checked. Maybe it needs a "spike" experiment.

Another XML parser that could be worth considering is fast-xml-parser, though again, I haven't tried it. It appears to support all the required features, but again, I haven't looked at the size.

If there is a library that uses the native parser when available, and can be compiled into both a "native" and a "not native" variant where the native one has a lower size and hopefully better performance, then I'm all in favour.

[bbert]

@nigelmegitt any strong feelings?

From the documentation for xmldom:

xmldom has an own SAX parser implementation to do the actual parsing

I suspect that changing sax.js for xmldom would likely increase the parsing duration and the minified size, though I haven't checked. Maybe it needs a "spike" experiment.

Another XML parser that could be worth considering is fast-xml-parser, though again, I haven't tried it. It appears to support all the required features, but again, I haven't looked at the size.

If there is a library that uses the native parser when available, and can be compiled into both a "native" and a "not native" variant where the native one has a lower size and hopefully better performance, then I'm all in favour.

Another XML parser to consider that claims to be faster than fast-xml-parser and with very smal bundle size: tXml.

This tXml parser is included in next dash.js v5 for MPD parsing.