Issue 493 - First draft of data type description #495

kstreeter · 2018-08-24T20:41:02Z

This PR addresses #493 by defining the logical type model for XDM, and adding a new meta:xdmType attribute to the meta schema.

cfraser · 2018-09-05T22:21:48Z

docs/data_types.md

+| --------- | --------------------------------------------------------- | ---------------- | ------------------ |
+| string    | unlimited                                                 | string           |                    |
+| number    | ±2.23×10^308 to ±1.80×10^308 (IEEE 64-bit floating point) | number           |                    |
+| long      | (-2^53 + 1) - (2^53 + 1) (54-bit signed integer\*)        | integer          |                    |


Should this not be a true 64 bit long? It's only javascript that is constrained right?

For interoperability with Javascript, we have to define it within the constraints of what Javascript environments can support, which is the 54-bit signed range.

I thought we agreed in another thread to not do that - and instead leave it full 64bits, but consider that some implementations can't handle that...

@lrosenthol, are you saying that we should just call the range as 64-bit, leave the note that that in practice its only 53-bit?

I feel like we should just acknowledge the limitation here. The JSON/Javascript ecosystem only really supports a 54-bit integer. We want to interop with JS, so we adopt the same.

lrosenthol · 2018-09-17T19:12:20Z

docs/data_types.md

+| --------- | --------------------------------------------------------- | ---------------- | ------------------ |
+| string    | unlimited                                                 | string           |                    |
+| number    | ±2.23×10^308 to ±1.80×10^308 (IEEE 64-bit floating point) | number           |                    |
+| long      | (-2^53 + 1) - (2^53 + 1) (54-bit signed integer\*)        | integer          |                    |


I thought we agreed in another thread to not do that - and instead leave it full 64bits, but consider that some implementations can't handle that...

lrosenthol · 2018-09-17T19:12:53Z

docs/data_types.md

+| short     | -2^15 - 2^15 (16-bit signed integer)                      | integer          |                    |
+| byte      | -2^7 - 2^7 (8-bit signed integer)                         | integer          |                    |
+| boolean   | { true, false }                                           | boolean          |                    |
+| date      | n/a                                                       | string           | date               |


you should put references to 3339 or 8601 on the various dates

This is fixed in the latest commit

lrosenthol · 2018-09-17T19:20:10Z

docs/data_types.md

+| date      | n/a                                                       | string           | date               |
+| date-time | n/a                                                       | string           | date-time          |
+| array     | n/a                                                       | array            |                    |
+| object    | n/a                                                       | object           |                    |


do you really mean object here or is this the "map" that you want?

cdegroot-adobe · 2018-09-25T18:20:56Z

@lrosenthol @kstreeter - I vote for the max being Number.MAX_SAFE_INTEGER ((2^53)-1)

My thinking:

JSON-LD is built on JSON-Schema which is built on JavaScript. The latter has the 53-bit Number limit ((2^53)-1).

type is constrained to what JSON allows

xdmType further refines, but cannot limit the constraints of type

Thus to my mind our long needs to be limited to Number.MAX_SAFE_INTEGER.

We have to accept that baggage or else say XDM is a special case, which we will end up having to repeat in perpetuity. I know it sucks, but we need to hold to consistency.

If you need really big numbers, they need to be string encoded.

cdegroot-adobe · 2018-09-25T18:23:37Z

docs/data_types.md

+| --------- | --------------------------------------------------------- | ---------------- | ------------------ |
+| string    | unlimited                                                 | string           |                    |
+| number    | ±2.23×10^308 to ±1.80×10^308 (IEEE 64-bit floating point) | number           |                    |
+| long      | (-2^53 + 1) - (2^53 + 1) (54-bit signed integer\*)        | integer          |                    |


@kstreeter That range seems wrong to me, should it not be:
-(2^53 - 1) to (2^53 - 1) (54-bit signed integer*)

There is an error here @cdegroot-adobe, although the range you suggested is not correct either. From RFC 8259 section 6:

Note that when such software is used, numbers that are integers and
are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.

Fixed two small typos, no semantic changes.

lrosenthol · 2018-09-26T12:04:57Z

@cdegroot-adobe - we have previously agreed that while the original JSON design (and the name) was built around JavaScript, neither JSON-LD nor JSON-Schema is built on JavaScript or its limitations.

That said, provided that we can resolve the xdmType issue, then I am OK with putting this limitation on XDM's long and saying that if you need something larger you must use BigNum - but that means we finalize that piece of work at the same time.

Fix the range for JSON integers

kstreeter · 2018-09-27T16:48:36Z

Thanks @lrosenthol. I filed issue #519 to track the need for BigDecimal/BigInteger types in XDM.

kstreeter and others added 2 commits August 24, 2018 13:39

first draft of data type description

d627581

Fix the table

b9d69d7

kstreeter mentioned this pull request Aug 24, 2018

Define Logical Data Types for XDM #493

Closed

fix lint

c52d8e5

cfraser reviewed Sep 5, 2018

View reviewed changes

lrosenthol reviewed Sep 17, 2018

View reviewed changes

kstreeter and others added 2 commits September 19, 2018 10:01

Merge branch 'master' into issue-493

264255a

responding to PR feedback

3191900

kstreeter added this to the 0.9.6 milestone Sep 24, 2018

cdegroot-adobe reviewed Sep 25, 2018

View reviewed changes

Trivial

71d026f

Fixed two small typos, no semantic changes.

Update data_types.md

e5b1ded

Fix the range for JSON integers

Update meta.schema.json

c2dce4d

kstreeter merged commit b0c0c6b into master Sep 27, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue 493 - First draft of data type description #495

Issue 493 - First draft of data type description #495

kstreeter commented Aug 24, 2018

cfraser Sep 5, 2018

kstreeter Sep 14, 2018

lrosenthol Sep 17, 2018

kstreeter Sep 18, 2018

lrosenthol Sep 17, 2018

lrosenthol Sep 17, 2018

kstreeter Sep 19, 2018

lrosenthol Sep 17, 2018

cdegroot-adobe commented Sep 25, 2018

cdegroot-adobe Sep 25, 2018 •

edited

Loading

kstreeter Sep 27, 2018 •

edited

Loading

lrosenthol commented Sep 26, 2018

kstreeter commented Sep 27, 2018

Issue 493 - First draft of data type description #495

Issue 493 - First draft of data type description #495

Conversation

kstreeter commented Aug 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdegroot-adobe commented Sep 25, 2018

cdegroot-adobe Sep 25, 2018 • edited Loading

Choose a reason for hiding this comment

kstreeter Sep 27, 2018 • edited Loading

Choose a reason for hiding this comment

lrosenthol commented Sep 26, 2018

kstreeter commented Sep 27, 2018

cdegroot-adobe Sep 25, 2018 •

edited

Loading

kstreeter Sep 27, 2018 •

edited

Loading