Difficulty treating some numeric tags as string

[chris-gilbert-2]

Description

I have an input structure where some numeric values are to be treated as strings. Rather than calling toString in multiple places in my code, I hoped to use the parsing options, but looking at the codebase I think it is not currently possible using either numberOptions or tagValueProcessor.

Input

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <id>132330</id>
    <nested>
          <id>191458</id>
          <count>1500</count>
    </nested>
</root>

Code

  const options = {
   tagValueProcessor: (tagName: string, tagValue: unknown) =>
      tagName === "id" ? `${tagValue}` : tagValue,
  };
  const parsed =  new XMLParser(options).parse(input);

Output

{
  '?xml': '',
  root: {
    id: 132330,
    nested: { 
      id: 191458, 
      count: 1500 
    } 
  }
}

expected data

{
  '?xml': '',
  root: {
    id: '132330',
    nested: { 
      id: '191458', 
      count: 1500 
    } 
  }
}

I see why there is no conversion - the input type is string and so is the output type, so when the tagValueProcessor is applied, parsing is not skipped.

I can't use the skipLike property of numberParseOptions because strnum only receives the value without the tag name for context. I can't safely use a regex to differentiate IDs from other numbers.

I can't use the parseTagValue option because that is a universal setting that can't be applied to specific tags.

I think the simplest (backward compatible) approach that would work for me, would be another option like parseTagValue, but which takes a function with the same inputs as tagValueProcessor or isArray, and returns boolean, so that enabling parsing can be finer grained.

Would you like to work on this issue?

• Yes
• No

Bookmark this repository for further updates. Visit SoloThought to know about recent features.

[github-actions]

We're glad you find this project helpful. We'll try to address this issue ASAP. You can vist https://solothought.com to know recent features. Don't forget to star this repo.

[amitguptagwl]

You can also try v5 experimental changes. But no detail tutorial is available currently. You can follow this guideline.

[enjdusan]

I have a similar issue, where it tries to parse number-like value to number.
For instance

<Address>
    <Udprn>09123456</Udprn>
</Address>

gets parsed into number

{ Address: { Udprn: 9123456 } }

which is obviously wrong, because it throws away leading 0 as it converts a string to a number.

[amitguptagwl]

Have you tried numberParseOptions?