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

KDL Schema: clarify definition of "format" #235

Open
nichtich opened this issue Oct 12, 2021 · 1 comment
Open

KDL Schema: clarify definition of "format" #235

nichtich opened this issue Oct 12, 2021 · 1 comment

Comments

@nichtich
Copy link

KDL Schema Specification includes format for string and number validation to control the "Intended data format" but KDL does not know the concept of data formats. What should a validator check with format?

  • the tag/type of a value (this is already covered by tag, isn't it?)
  • for strings the pattern (so ISO8601 and several other specifications are mandatory references to the spec)
  • for numbers the serialization (this is not required to be preserved)
  • the internal representation of a value (this should out of the scope of KDL Schema)
@swift2plunder
Copy link
Contributor

While internal representation is likely out of scope and probably should remain so, the same can't be said of the effects. Underflow in single precision floats was recently cited as argument that KDL would be better with a stronger opinion on numeric formats

The argument is that there exists a number, N, that can be safely represented in a 32 bit float, for which there is a value N+1 that could be correctly parsed and stored as a 64 bit float, but would render as N if stored as a 32 bit float. As long as we're talking about a tractable number of such cases, like overflow and underflow errors possible with the formats listed in the schema document, I'm prepared to identify N and write test cases for attempting to roundtrip N+1, though I'll have some questions in the process

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants