It should be possible to define partial temporal values but only for trailing precisions (i.e., if you specify a day, you must also specify a year and month)
Values of type Date, the precision unit must be one of: years, months, or Days
e.g. date( 2019 ), date( 2019, 09 ), date( 2019, 09, 17)
Values of type Time, the precision unit must be one of: hours, minutes, or seconds
e.g. time( 09 ), time( 09, 55), time( 09, 55, 00)
Values of type Date and Time, the precision unit must be one of: years, months, days, hours, minutes, or seconds
e.g. date and time( date(2019,09,17), time(09,55) ), date and time( “2019-09-17T09:55”)

Operations carried out on elements with different time based precision units shall be done based on the lowest common precision unit (truncating any resulting decimal portion) 

In many situations, it is desirable to have a data input that is an interval. Particularly when it comes to temporal logic many situations requires one to enter the "Valid Period", the "Measurement Period", the "Disccount Period" etc
To currently achieve this requires to create two data inputs (one for the start data/time and one for the end data/time) and then assembling them into an interval named "Period using a literal expression [start..end].

Add a new interval built-in function called: width of( Interval )
to offer the behavior as follows:
width of( (1..10] ) = 9
width of( [1..10] ) = 10
width of( (1..10) ) = 8
width of( [ time(“09:55:00”)..time(“10:35:00”) ] ) = PT40M

A "bucket" for collecting related issues around external links

In other sections in the spec, InformationItem is described as storing the data through an ItemDefinition or Expression. Figure 6.16 shows that InformationItem has a /type association with ItemDefinition. Other figures show this also.
But the table in the section on InformationItem (7.3.4) doesn't list this association and ItemDefinition is not mentioned in the section.

Subsection "6.2.2.2 Knowledge Requirement notation" of "6.2.2 DRD Requirements" states that knowledge requirements must be utilised in the decision/BKM knowledge requirement:

"If e is a decision or a BKM in some DRD, and e contains a knowledge requirement on some invocable element b, then the logic of e must contain an invocation expression of b, including expressions for each of b's parameters."

However, this section does not mandate that Information Requirements must also be utilised by the requiring DRG element in the same way that a knowledge requirement must. If a purpose of DMN is to serve as documentation and show actual relationships between decision elements then it is paramount the DRG reflects actual usage in the model, otherwise the graph is incorrect - it may show relationships that do not reflect the decision-making reality.

I propose adding the following to section "6.2.2.1 Information Requirement notation":

"If e is a DRG element in some DRD, and e contains an information requirement on some other DRG element b, then the logic of e MUST contain a usage of the information provided by b"

Section "10.3.2.13.2 User-defined functions" provides definition and invocation semantics for user defined functions but permits unused parameters.

As DMN is to be 'executable documentation' I suggest that unused parameters provide documentation that does not reflect reality.

I propose the follow additional paragraph to "10.3.2.13.2 User-defined functions" :

"The body expression of a user-defined function SHALL utilise every formal parameter. "

Section "10.5.3 FunctionDefinition metamodel" does not specify that formal parameters must be utilised in the function logic . As DMN is a self-documenting decision executable this leads to a situation where (documented) parameters may be defined but unnecessary.

I propose the following paragraph is added to section "10.5.3 FunctionDefinition metamodel":

"The body expression of a FunctionDefinition SHALL utilise every formal parameter. "

Section 9.4 says "Comparison operators are defined only when the two operands have the same type, except for years and months duration
and days and time duration, which can be compared for equality. Notice, however, that “with the exception of the zerolength
duration, no instance of xs:dayTimeDuration can ever be equal to an instance of xs:yearMonthDuration.”

Thus stating that `P0D == P0Y` despite the fact they are different types and do not comply with the type-lattice equivalency. This is as per the XPATH operation `op:duration-equal` that the spec says equality here conforms to.

It is not crystal clear if this applies to FEEL as well as SFEEL though the same sections does say:

> The semantics of S-FEEL expressions are defined in this section, in terms of the semantics of the XML Schema datatypes
and the XQuery 1.0 and XPath 2.0 Data Model datatypes, and in terms of the corresponding functions and operators
defined by XQuery 1.0 and XPath 2.0 Functions and Operators (prefixed by “op:” below). A complete stand-alone
specification of the semantics is to be found in clause 10.3.2, as part of the definition of FEEL. Within the scope of SFEEL,
the two definitions are equivalent and equally normative.

So, "Within the scope of SFEEL, the two definitions are equivalent and equally normative." seems to indicate that it does hold true for FEEL.

My recommendation is that `P0D == P0Y` does apply to FEEL because it would make sense to a business person. `1 Apple != 1 Orange`, but zero apples is really the same as zero oranges, or zero anything for that matter. And, in practice, zero days really is the same as zero years.

The new is() function is in a spec section called "Date and time functions" but it is unclear if it related only to date and time types. The examples only show date and time. Though it would seem reasonable that is also handled datetime type as well.

Additionally, it references section 10.3.2.2 for descriptions of semantics and that section deals with ore than just date and time. It also deals with other 'primitive' types - so it is unclear if is() relates to these also. Additionally, that section does not deal with other types like range/context/function/list so it is not clear if is() deals with all types in that section, and indeed other types as well.

By example, is it not evident if is({},{}) is true, false, or illegal. Similarly for is([1], [1]) or is(1,1), or is([null..2], < 2).

Additionally, it is also unclear (to me) from the semantic description whether is(@"2021-02-19T10:10:10Z", @"2021-02-19T10:10:10@Etc/GMT") as they are both UTC forms. The spec says they are 'comparable', but does that relate to is()?

The `parameters` attribute of the new FunctionItem introduced in DMN 1.3 is plural in name and not singular like all other array attributes described in the meta-models. This is an exception.

This leads to an XML form where each `<parameters>` element contains one parameter.

Recommendation. Change FunctionItem array attribute `parameters` to `parameter`. Another possibility is to deprecate `parameters` in favour of `parameter` and drop support in a future version.

Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see DMN14-123 for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.

The `before` and `after` range functions have ambiguous invocation when using named params. Both functions have 4 variants - take `before` as an example:

```
(a) before(point1, point2)
(b) before(point, range)
(c) before(range, point)
(d) before(range1, range2)
```

If I invoke `before(range: [1..10], point: 1)` is it for variant (b) ... or (c) ... ?

Suggest renaming the param names or making the variants separate functions.

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
UnaryTest should be added to the diagram.

SDMN, BPMN, and CMMN have a property that specifies the kind of element that is being modeled. The set of enumerations for this property include: data, conceptual, physical, etc.
SDMN is directly referencing DMN’s ItemDefinition, but is extending the element to include this “itemKind” property.
If this property makes sense in the DMN context and is added in DMN 1.4, then SDMN would not have to extend ItemDefinition for this property.
SDMN extends ItemDefinition in other ways, which will be addressed by separate issues.