fn:elements-to-maps: Types

[ChristianGruen]

Copied from #1592 (comment):

With regard to types, I would propose to introduce a separate option:

elements-to-maps(
  <value>42</value>,
  { 'types': { 'value': 'number' } }
)

→ { "value": 42 }

I have a preference for strings, as we can prefix them with @. Next, the representation could be identical to the result, which I believe is more intuitive:

elements-to-maps(
  <value count='3'/>
  { 'types': { '@count': 'number' } }
)

→ { "value": { "@count": 3 } }

Of course, we could also have two options (element-types, attribute-types).

[michaelhkay]

I think we have a mechanism for defining the types of values, called XSD validation, and we shouldn't invent another.

[ChristianGruen]

One more question, probably stupid enough, due to my XSD ignorance. The example for the simple-plus layout is:

<price currency="USD">23.50</date>

The presented result is:

"price": { "@currency": "USD", "#content": 23.50 } }

The mapping rules say:

If the element has been schema-validated, the types of the items in the atomized value are retained.

Does the example imply that the string value of the price element is of type xs:decimal, due to schema validation?

Would it be possible/reasonable to include an ideally self-contained example that shows how a user may end up with a map that contains numbers? I guess there will be no chance to achieve this for ad-hoc data and without the full XSD machinery?

But I see your point, and I did not consider in my suggestion that we are creating maps (not JSON), which makes the challenge much more complex. I will be happy to close this if no one else jumps in.