Backwards compatibility with popular libraries

[Redsandro]

The value of this library increases if it can be configured to build the resulting object similar to popular projects like rapidx2j, nkit, x2je, xml2json and xml2js. It would instantly become a drop-in replacement for each of those libraries used in other node projects.

In order to do that, you'd need to:

1. add nodes with their tagName as keys to an object rather than values to a property;
2. group attributes to a key with a custom name, in this case "@";
3. only turn the object of the tagName key into an array if the tagName occurs more than once.

Would you be interested in adding the option(s) to do so?

Example: In stead of this:

[
  "children": [
    {
      "tagName": "child1",
      "attributes": {},
      "children": [
        {
          "tagName": "child2",
          "attributes": {},
          "children": [
            {
              "tagName": "child3",
              "attributes": {},
              "children": [
                "tagName": "child4",
                // ...

We need to end up with this:

{
  "child1": {
    "@": {},
    "child2": {
      "@": {},
      "child3": {
        "@": {},
        "child4": [
          // ...

---

In response to Redsandro/node-xml2js-olympics#1

[TobiasNickel]

interesting interesting, indeed, interesting times two, thanks for considering to add txml. and I understand the conditions have to be fair and the task the same. And yes, I love the idea of drop-in replacement.

txml currently has two transformation functions that take the DOM and turn it into a more convenient data structure. simple is the same as php simpleXML. and recently I added a lostless version, that keeps every key an array and has attributes in _attributes. I think for the benchmark, transforming the DOM into the data structure that you describe is similar to the other two transformations. But I wonder if the code has to behave according to a configuration, that would put a hit on performance. Using a technique similar to fast-json-stringify could keep the speed up. At some point I would think that adding more transformation functions would belong into userland. Maybe a separate module txml2js is a better place (just made a reservation on the name), as the txml module should stay small bundles in web or cloud-functions.

Not sure when I get to implement such feature.

Thanks for getting in contact @Redsandro @strarsis

[Redsandro]

Thanks for the response @TobiasNickel.

Some of the binary implementations (nkit, rapidxml) are quite fast compared to native javascript (xml2json being a popular one), but those modules are 3 to 6 years old and to the best of my knowledge no one really made another attempt.

Your method could be a lot more efficient; the overhead might not necessarily be due to configurable object creation.

If you get around to such a thing, please tag me here or on Redsandro/node-xml2js-olympics#1.

Keep in mind that a transformation in userland would be less efficient because you would traverse the data twice.

[Redsandro]

A drop-in replacement option, especially native javascript, would be appreciated because some older modules are getting harder to compile on newer node versions. 👍

[TobiasNickel]

I had the idea, it might even be possible to help xml2js to migrate from sax to txml. Similar to the PR I made to svgo it can be possible to change the parser class in xml2js to rely on txml`. mostly: only such opinionated reducer function is needed to do that.

When doing this work, I think xml2js can be faster as well as easier to install. Without c modules.

[Redsandro]

it might even be possible to help xml2js to migrate from sax to txml.

The inner workings of these parsers are too complex for me to weigh on. I'm afraid I can't comment on the viability of such migration, keeping in mind that the output needs to be identical for the result to be a drop-in replacement for all the dependent projects out there. But I certainly encourage you to try if you believe it is viable!

If you or someone else makes a cloneable PR for xml2js, tag me again so I can benchmark and compare against the older version.

Similar to the PR I made to svgo it can be possible to change the parser class in xml2js to rely on txml`.
For reference: svg/svgo#1301