Start draft of KDL Data Model #228
Conversation
* Include suggestions from review * Add missing tags on values * Add sections on data binding and limited support of the data model
| ### Limitations to the data model | ||
|
|
||
| Implementations may choose to limit the set of processable KDL documents for | ||
| technical reasons. Such limitations must be stated clearly to indicate a useful | ||
| but incomplete support of KDL data model. Reasonable limitations include: | ||
|
|
||
| * Precision of numbers | ||
|
|
||
| * Types of elements that can have tags (e.g. disallow tags for boolean values | ||
| and `null`) | ||
|
|
||
| * Unicode Normalization (e.g. collapse properties into one when their names are | ||
| equivalent after normalization) | ||
|
|
||
| Implementations must document how limitations to KDL model are applied when KDL | ||
| document are read (e.g. give warnings and ignore unsupported elements). |
There was a problem hiding this comment.
I forgot tags on values in the data model. Things like unlimited precision numbers and type annotations of a null may be needless for many implementations so they may chose to not support the full data model. Nevertheless these edge cases are part of the model and may have use cases (e.g. (unknown)null vs. (not-applicable)null).
There was a problem hiding this comment.
Given that numbers and strings don't have a "tag" concept natively in any language I know of, and thus have to be handled with kdl-specific data types anyway, requiring tags to be supported on bools/nulls as well doesn't seem to be any additional burden.
There was a problem hiding this comment.
Ok, this section is non-normative anyway and does not need to be part of the data model document. Maybe the section should better explain difference between syntax, parsing, and data model (again?). Treatment of tagged numbers and may need further description anyway: KDL Schema mentions format without reference to tag/type.
|
+1, these changes are nice. I can update the tests to mandate empty tags not be preserved in serialization once this is merged. |
|
moving this to kdl-v2 |
I don't think the data model breaks the KDL spec because KDL spec does not define how to internally store the result of parsing. A model is more important for KQL and KDL Schema. Nevertheless it would help to state that a KDL parser MUST preserve at least the information covered by the data model. |
|
Agreed, this should just be capturing the assumptions inherent in the test-suite, and so is suitable for v1. |
zkat
removed
the
breaking
|
Noted. Moved back :) |
|
Shall we roll this up as part of KDL 2.0? |
Thanks for discussion (#225). In addition to further changes to the specification of KDL Data model, the document should be referenced from other documents in this repository.