Data Type Definition: REQUIRED OR OPTIONAL DATA

[Weaver Swenson]

I am looking for a way in DMN to declare that a piece of data is required or optional.   This is often called nullable and not nullable.  If a data item is marked as optional or nullable, then if it is not present, the value null is used for it.  If a data items is defined as required or not nullable, then if the data item is missing it is an error.

DMN data types can require an enumerated set of values.  They can define a require range for the value.  However I am not finding a way to state that a field is nullable or not.

I did note that Trisotech has some kind of annotation to indicate this, but I don't know how that is stored in the DMN file.  Does anyone know?  I assume it is a proprietary extension to the DMN format.

This seems like a required feature in DMN data type definition.  Any suggestions on how to store this in a DMN file?

p.s. if there is a better place to discuss this sort of thing let me know.

[Octavian Patrascoiu]

DMN 1.5 adds support for constraints at the ItemDefinition level

https://www.omg.org/spec/DMN/1.5/Beta1/PDF

Table 26: ItemDefinition attributes and model associations

 

Hope this works for you

Octavian

--
You received this message because you are subscribed to the Google Groups "DMN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dmn-communit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/dmn-community/c26dd711-1965-41f7-821e-940180d2bb2fn%40googlegroups.com.

[Denis Gagne]

Hi Keith

For enumerated values, Trisotech does not use extensions to serialize the concept that it can either be absent (null) or a value.

As an example, a type that can be either “a”, “b” or “c” is serialized in DMN with an allowedValue of “a”,“b”,”c”,null

[Weaver Swenson]

Octavian,

Thanks for the link.  It is not immediately obviously how "typeConstraint" applies to whether the value is required or optional.  I suppose you might put a "not null" in there, and that would allow for a failure if the value is missing or null.  I guess ever value might then need to satisfy this constraint.  I suppose you can AND and OR conditions together to get a more complex requirement.  That is a good tip.

thanks,

-Keith

[Weaver Swenson]

Denis,

Thanks!  That is quite a clever way to do it when you have an enumeration.  Just check if null is one of the values, and a missing value is allowed.  (Well, null is allowed technically.)  In the DMN Modeler UI where I saw something about all null, is that what it is controlling?

I don't think this solves the problem or requiring, for instance, that a bank account number be provided, and to fail if it is not.  Looks like the upcoming typeConstraint will probably meet that need.

-Keith

[Weaver Swenson]

It is worth mentioning that JSON schema does this a little differently.  The type itself is not required or optional, but the place where it is used.  Thus SSN as a type is not always required.  It may be require in the seller's record, but the very same type might not be required in a buyer's record.  It is not a property of the type, but a property of the structure definition.  I am pretty sure that is the better way to go, since the required/optional  (nullable or not nullable) is really a relationship between a structured compound type and the data member.

I am doing most if my internal manipulations using JSON schema.  One can translate from DMN type defs into JSON schema, but there are some cases where you can't go the other way.

-Keith

On Tuesday, September 26, 2023 at 2:54:51 AM UTC-7 opatr...@gmail.com wrote: