Skip to content
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

Merged
merged 8 commits into from
Sep 27, 2018
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/data_types.md
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 | |
Copy link
Contributor

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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...

Copy link
Collaborator Author

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.

Copy link
Contributor

@cdegroot-adobe cdegroot-adobe Sep 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

@kstreeter kstreeter Sep 27, 2018

Choose a reason for hiding this comment

The 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:

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.

| 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 |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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 | |
Copy link
Collaborator

Choose a reason for hiding this comment

The 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.
1 change: 1 addition & 0 deletions docs/introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,3 +86,4 @@ This means, if the JSON representation of two XDM models is identical, then the
4. [Abstract and Concrete Schema](abstract.md)
5. [Schema Status](status.md)
6. [Identifiable Entities](id.md)
7. [XDM Logical Data Types](data_types.md)
17 changes: 17 additions & 0 deletions meta.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,23 @@
"https://ns.adobe.com/xdm/common/desciptors/schemadescriptor#/definitions/descriptor"
}
},
"meta:xdmType": {
"description": "signals the logical data type of a field",
"type": "string",
"enum": [
"string",
"number",
"long",
"int",
"short",
"byte",
"boolean",
"date",
"date-time",
"array",
"object"
]
},
"type": {
"type": "string",
"const": "object"
Expand Down