Project

Profile

Help

Actions
Send by e-mail Copy link

Feature #6383

closed

Extend SaxonJS.atom to support more types

Added by Norm Tovey-Walsh 4 months ago. Updated 27 days ago.

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

0%

Estimated time:
Applies to JS Branch:
Trunk
Fix Committed on JS Branch:
Trunk
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 4 months ago

Option (1) looks best to me.

Actions
Copy link
 #2

Updated by Michael Kay 4 months ago

Better still

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

Actions
Copy link
 #3

Updated by Norm Tovey-Walsh 4 months ago

Using a map is an interesting idea.

Actions
Copy link
 #4

Updated by Norm Tovey-Walsh 4 months 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"))
Actions
Copy link
 #5

Updated by Norm Tovey-Walsh 27 days ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Resolved

In the course of a couple of rewrites, this work got refactored then scaled way back. I'm not saying it isn't a good idea, but it's not on the critical path for anything anymore.

I have extended atom() to support converting Uint8Array objects into either hexBinary or base64Binary.

Actions
Copy link
 #6

Updated by Debbie Lockett 27 days ago

  • Category set to API
  • Applies to JS Branch Trunk added
  • Fix Committed on JS Branch Trunk added

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF Tracking page