-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 493 - First draft of data type description #495
Changes from 3 commits
d627581
b9d69d7
c52d8e5
264255a
3191900
71d026f
e5b1ded
c2dce4d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
# XDM Logical Data Types | ||
|
||
XDM schemas are defined in terms of JSON Schema and therefore inherit a type model from JSON. While this allows XDM to describe data types represented in JSON directly, it is useful to define the basic logical data types more specifically so that the XDM data model can be more easily mapped to non-JSON representations. | ||
|
||
## Data Type Definitions | ||
|
||
The following table describes the available data types: | ||
|
||
| XDM type | Range | JSON Schema type | JSON Schema format | | ||
| --------- | --------------------------------------------------------- | ---------------- | ------------------ | | ||
| 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 | | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kstreeter That range seems wrong to me, should it not be: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is an error here @cdegroot-adobe, although the range you suggested is not correct either. From RFC 8259 section 6:
|
||
| int | -2^31 - 2^31 (32-bit signed integer) | integer | | | ||
| 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 | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you should put references to 3339 or 8601 on the various dates There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is fixed in the latest commit |
||
| date-time | n/a | string | date-time | | ||
| array | n/a | array | | | ||
| object | n/a | object | | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do you really mean object here or is this the "map" that you want? |
||
|
||
* While conceptually JSON numbers have no limits on range, in practice they are assumed to be represented as IEEE 64-bit floating point numbers. A JSON Schema integer is represented as the set of numbers that don’t have a decimal part. When this is mapped to what can be represented in 64-bit floating point format, the effective range is approximately that of a 54-bit signed integer (shifted by 1). While this can easly be represented as a 64-bit signed integer, processors must take care not to exceed the valid range when exchanging data between services as XDM. | ||
|
||
## Describing XDM Data Types in JSON Schema | ||
|
||
All fields defined in an XDM schema are interpreted as one of the above types. This interpretation is based on the specified type of the field (via the `type` attribute), the format of the field when present (via the `format`) attribute, and the specified range of the field (via the `minimum` and `maximum` attributes). | ||
|
||
Integer fields are interpreted as the smallest integer data type that can contain the specified range. For example, if a "dayOfMonth" field has a minimum value of 1, and a maximum value of 31, it will be intepreted as a "byte" XDM type. | ||
|
||
## Explicitly Signaling XDM Data Types | ||
|
||
To make interpreting data types from the JSON Schema definition less error prone, schemas MAY explicitly signal the intended data type using the `meta:xdmType` attribute. Explicit signaling of types is optional. Even when the `meta:xdmType` attribute is present, schemas MUST fully define the field in terms of type, format, and range. When the `meta:xdmType` attribute is encountered, processors MUST verify that the JSON Schema description of the field matches the signaled type. When the JSON Schema description of a type and the signaled type do not match, the schema MUST be considered invalid. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be a true 64 bit long? It's only javascript that is constrained right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.