Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #6383

open

Extend SaxonJS.atom to support more types

Added by Norm Tovey-Walsh 24 days ago. Updated 21 days ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2024-04-05
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

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?

Actions
Copy link
 #1

Updated by Michael Kay 24 days ago

Option (1) looks best to me.

Actions
Copy link
 #2

Updated by Michael Kay 24 days ago

Better still

SaxonJS.atom({year:2024, month:4, day:5}, "date")

Actions
Copy link
 #3

Updated by Norm Tovey-Walsh 24 days ago

Using a map is an interesting idea.

Actions
Copy link
 #4

Updated by Norm Tovey-Walsh 21 days ago

I scratched out a quick alternative implementation of atom() that supports map values in a way that I think is mostly backwards compatible. If no type is specified, you get one of boolean, number, or string. If a type is specified, you get that type. For the types QName, gDay, etc., time, yearMonthDuration, and dayTimeDuration, the first argument has to be an object and the keys are tested for correctness. The following examples all return the correct values:

      console.log("number: ", SaxonJS.atom(17))
      console.log("float: ", SaxonJS.atom(17, "float"))
      console.log("date: ", SaxonJS.atom(new Date(), "date"))
      console.log("qname: ", SaxonJS.atom({"local-name": "test"}, "QName"))
      console.log("ymd: ", SaxonJS.atom({"years": 57, "months": 9}, "yearMonthDuration"))

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF Tracking page