DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

"Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.

Since DMNv1.2 the spec dropped the equivalence of:

[a] = a

because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression

[a] = a

on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:

To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:

get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "

BUT

get entries({key1 : "value1"})[key="key1"].value = "value1"

  by substitution:

[ { key : "key1", value : "value1" } ][key="key1"].value = "value1"
[ { key : "key1", value : "value1" } ].value = "value1"
[ "value1" ] = "value1"

according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:

[123] = 123

on DMNv1.2 is expected to be false

In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.

some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?

Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.

The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds

the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.

The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

I propose that after the definition of well-formed on page 56/57 (repeated below):

"An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

The following paragraph is added:

"However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."

E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly

split off from DMN13-12

All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
Does anyone think this is a good idea?

The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

Date "=" is defined to include the time zone, and "<" and ">" does not. This causes a bunch of problems.

see: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

Suggestion is simple: define date equality to be (date1 - date2 == 0) Eliminate the need to compare the "timezone" of the dates.

My experience with the group is that most suggestions are ignored, so I don't really want to waste any time making a more detailed proposal, but if you have questions about this problem you can contact me.

The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.