Support for xsd:int and xsd:long in framing

[ioggstream]

I expect

• jsonld.frame to serialize xsd:int and xsd:long to JSON Number

Instead

• serializes to JSON String

[ioggstream]

@davidlehn I'm implementing this against master.

Should I implement this against 2.0.4 to have a release?

[davidlehn]

There is more to this than changing the code. The current JSON-LD 1.1 spec algorithms only say what to do with xsd:integer as far as integers go. I seem to recall we discussed if or how to support other xsd numeric types, but I forget the details (they may be in the meeting archives). We probably decided the initial focus should be basic support that aligned with JSON. Or perhaps there were round-trip issues that were too complex. And there are probably out-of-bounds sorts of issues here too. And we probably ran out of time to do more.

Changing the algorithm in only pyld could present compatibility problems. The same data in other implementations would produce different results. Similar if users expect spec conformant behavior, then defaulting to treating other xsd types as native would be a surprise.

I'm not sure what the easy answer is here. I think there should be a way to explore optional extensions to do things like this. The concept itself is useful. And such changes could move into the main spec as they mature. But I think the default should be strict spec behavior.

(I'm soon going to propose an RFC-like system to help have a place to develop ideas like this. I'll add it to a list of possible ideas.)

I know it's more work, and has an unknown timeline, but the issues here should be brought up in the json-ld-api spec repo. Eventually would need main test suite tests to ensure all implementations handle this the same way.

[ioggstream]

Hi David,

There is more to this than changing the code. The current JSON-LD 1.1 spec algorithms only say what to do with xsd:integer as far as integers go.

Ok, so it is formally limited to https://www.w3.org/TR/json-ld-api/#rdf-to-object-conversion .

XSD has built-in datatypes where:

• some are primitive (e.g., string, boolean, decimal, float, double, ... )
• some are "other" (e.g., language, integer, long, int, short, byte, ... )

xsd:integer derives from xsd:decimal
xsd:long derives from xsd:integer
xsd:int derives from xsd:long

While I understand what the specification says, given that xsd:long, xsd:int, xsd:short are just xsd:integer with restrictions, I think that the conversion is loseless here, as long as the @context preserves the original @type.

I seem to recall we discussed if or how to support other xsd numeric types, but I forget the details (they may be in the meeting archives). We probably decided the initial focus should be basic support that aligned with JSON. Or perhaps there were round-trip issues that were too complex. And there are probably out-of-bounds sorts of issues here too. And we probably ran out of time to do more.

Looking around, I found that there were concerns related to xsd:float and xsd:decimal, which is sensible since the @value could be altered.

Changing the algorithm in only pyld could present compatibility problems. The same data in other implementations would produce different results. Similar if users expect spec conformant behavior, then defaulting to treating other xsd types as native would be a surprise.

May be related to digitalbazaar/jsonld.js#554

I am considering to pre-process xsd:int to xsd:integer to achieve the expected result
to avoid modifying the library. I think that this is a limitation in JSON-LD spec though.

I'm not sure what the easy answer is here. I think there should be a way to explore optional extensions to do things like this. The concept itself is useful. And such changes could move into the main spec as they mature. But I think the default should be strict spec behavior.

I understand.

(I'm soon going to propose an RFC-like system to help have a place to develop ideas like this. I'll add it to a list of possible ideas.)

Let me know, since I am interested in the process!

I know it's more work, and has an unknown timeline, but the issues here should be brought up in the json-ld-api spec repo. Eventually would need main test suite tests to ensure all implementations handle this the same way.

OK. Looking forward to contribute more to this repo!