DMN 1.6b beta 1 - some issues , and notes re the TCK #680
Replies: 4 comments
-
|
From the meeting: 7.3.4 InformationItem metamodel question - a combination of a namespace and name is unique definition. The same DMN file can be imported transitively by multiple imports. The inputData referenced by namespace.name is a unique same value. (It is basically one "instance" of inputData). |
Beta Was this translation helpful? Give feedback.
-
|
From the meeting: Table 66: List of properties per type - This needs an issue in the DMN OMG to define the term "epoch" in the specification. |
Beta Was this translation helpful? Give feedback.
-
|
From the meeting: Page 136 descendant operators - Needs clarification in the specification, that it always returns a list. |
Beta Was this translation helpful? Give feedback.
-
|
From the meeting: For the error handling, we probably need to extend the test cases schema, to be able to handle errors. |
Beta Was this translation helpful? Give feedback.
-
From a read on the 1.6 beta - some things not quite clear and/or not specified. If we could discuss at this week DMN meeting that'd be great.
@baldimir @falko @SimonRinguette @opatrascoiu
DMN 1.6 Changebar notes
Issues
7.3.4 InformationItem metamodel
What defines its uniqueness? Is an inputdata variable name global to all imports now? What if the variable name is the
same but the type is different? In practical terms, how is data for an imported inputData now passed to a runtime for execution? (presently we assume a context named as per the import name with keys named as-per the input data in that imported model). Some example in the spec would be ideal as this is still not specified.
Table 66: List of properties per type
"value" added to date/time/duration types. Spec references other sections to details what "value" means, but according to those sections "date" and "date time" values are only relative to an "epoch" but the spec does not define what that epoch is. One might assume 1st Jan 1970, but it is not specified.
Table 73: Semantics of conversion functions
New overload for "number" function that takes either just a string or a number. If a number it is echoed. If a string it is parsed as a number. What locale assumptions are made regarding the string format? Is number("12.120") a little more than 12, or is it 12120? Like is the dot here treated as a decimal point or a thousands separator?
Single param version of rounding functions. Spec does not state what the default scale is. Would assume zero, but it is not said.
11. B-FEEL!
Nothing about compliance level mentioned here. Is it optional? Should we test for it in the TCK as an optional series of tests?
Page 136 descendant operators
Always creates a list? What if just one is found? What if none are found?
7.3.8 Error Handling
Not sure if there is anything for anybody to do here? Can we assert this in the TCK?
10.3.2.3.1 number
Numbers are now based on IEEE 754-2008 - what implications does this have?
Other Notes
Java is optional
8.2.11.1 Single and multiple hit tables
Text change to collect policy type - I think we've already got this.
10.2.1.7 Boxed Function
ONNX function type specifics. Optional for TCK.
10.2.1.9 Boxed filter
Implicit conversion to list
10.2.1.10 Boxed iterator
Implicit conversion to list
including "some" and "every"
10.3.1.2 Grammar rules
"descendant expression" in textual expression
Grammar point 68. descendant expression = expression , "..." , name ;
10.3.2.9.4 Type conversions
Check built-in tests for this. Not possible to define an integer for BKM I guess?
10.3.4.1 Conversion functions
zoned times are deprecated.
Table 73: Semantics of conversion functions
new overload for function "date and time" that takes a timezone string. Time param may not have a zone. Zone may be a time zone offset or an IANA zone identifier.
"date(year, month, day)" params are integer and are implicitly converted. Same for "time(hour, minute, second, millisecond)".
new overload for "number" function that takes either just a string or a number. If a number it is echoed. If a string it is parsed as a number. What locale assumptions are made regarding the string format? Is number("12.120") a little more than 12, or is it 12120? Like is the dot here treated as a decimal point or a thousands separator?
Table 73: Semantics of conversion functions
List functions with position / length arguments are integers.
Beta Was this translation helpful? Give feedback.
All reactions