Backwards compatibility with popular libraries

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 https://github.com/Redsandro/node-xml2js-olympics/issues/1

[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]

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