Saxon » SaxonJS

In the course of implementing new APIs for function calls, I created an API for constructing atomic values that largely overlaps SaxonJS.atom. That's silly. For lots of types, it makes more sense to reuse SaxonJS.atom. Unfortunately, there are atomic types that aren't supported:

QName
base64binary
date
dateTime
dateTimeStamp
dayTimeDuration
float *
gDay
gMonth
gMonthDay
gYear
gYearMonth
hexBinary
language **
time
yearMonthDuration

* float is supported, but gives subtly different answers. 
** language is supported, but fails to detect (some) invalid language identifiers

I'm tempted to extend SaxonJS.atom to support these, but what's the best approach?

The biggest problem is that the "type" argument is the second argument, so what should we do if we need more than one argument for the type? (Consider constructing a date from year, month, and day.)

We could:

1. Pass the parts as an array: SaxonJS.atom([2024, 4, 5], "date")
2. Pass the parts encoded in a string: SaxonJS.atom("2024-04-05", "date")
3. Overload the function: `SaxonJS.atom(2024, "date", 4, 5)
4. Overload the function: `SaxonJS.atom(2024, 4, 5, "date")

I think 1 or 4 are significantly better than 2 or 3. In some ways, I prefer 4 to 1, but on balance, I'm leaning towards 1. Or defining a whole new function: SaxonJS.atomicValue() with a different signature.

I also wonder about the semantics of SaxonJS.atom. Today it's very clearly implemented as a cast. I don't think that'll work for some of the types we need. Is that implementation strategy significant or was it just convenient?