DMN1.4 - why tChildExpression etc ?

[StrayAlien]

Hey all,

1.4 beta has landed. Not too much new stuff in there so I'll get into some tests.

But ... I can't figure why we need the tChildExpression type and sub types.

Other types just have expressions, like a ContextEntry just has an expression, not something that 'holds' an expression. A list is just a list of expressions, not a list of things that hold expressions. Likewise with everything else. So, in essence, they are just the same as their literal counterparts. A literal list is just a list of expressions, context entry is a name and an expression.

What is it about these new boxed types that needs this new type? I mean, an if/then/else box is surely just three named expressions, not three named things that hold an expression. Same for the other new boxed expressions. It means they are not the same as their literal counterparts. Like, the grammar for if/then/else is this:

if expression = "if" , expression , "then" , expression , "else" expression ;

Why does it need to be something different when boxed?

Not sure I get it, or have I missed something?

Comments welcome.

[StrayAlien]

bump

[baldimir]

@dmn-tck/contributors could you please take a look and provide an opinion?

[opatrascoiu]

Hi

The changes in the DMN schemas are tracked here https://github.com/opatrascoiu/omg-dmn-spec

I had a quick look at the changes. I tend to agree with @StrayAlien. It looks like 'tChildExpression' and 'tTypedChildExpression' are redundant - they extend tExpression by adding an id and typeRef, but tExpression already has them.

The metamodel at Figure 6-11: DMNElement Class Diagram looks fine.

@SimonRinguette Could you please explain the rationale behind this ? If there is an error we should raise an issue and fix it.

[SimonRinguette]

My recollection is that it was required to make it work for the XSD.

In the new decision logic, we can put more than just literal expressions in them and we need to leverage the substitiongroup called "expression" to allow to host either a boxed context, a decision table or any other type of expression. This would not be possible it if was a tExpression.

This concept in the spec only existed in boxed context and we did not want to introduce a specific element for each of the new decision logic type and created this abstract one.

[StrayAlien]

Hi @SimonRinguette / @opatrascoiu -

In the new decision logic, we can put more than just literal expressions in them and we need to leverage the substitiongroup called "expression" to allow to host either a boxed context, a decision table or any other type of expression. This would not be possible it if was a tExpression.

Isn't this what happens at the moment for all places where an expression may be used? Like, for example, a TList may contain a sequence of expressions, and, in practice those can be any boxed expression, not just a literal expression. The TCK has many tests that have this pattern whereby a boxed expression contains other types of expressions - not just a literal expression. And that is valid according to the schema. They are all leveraging the "expression" substitution group and this is (IMO) kind of 'normal'.

I do see that this is kind of different in that the new boxed expressions contain 'named' expressions but the names are not variable - unlike like a contextentry pairing of informationItem/expression. None of the other boxed expressions kind of have this notion of a static 'named expression'. I guess the closest is a context entry, and as a pairing of name and expression it is all wrapped in an element - a ContextEntry. So, similar.

I guess in support of this new construct we do not actually have 'named expressions' and expressions descend from DMNElement, not named element.

Btw, I'm not saying it is wrong and disagreeing with it, just seeking to understand the reasoning behind the new construct. I can kind of detect some reason - just not quite there as yet!

[opatrascoiu]

@StrayAlien @SimonRinguette
I've done some investigation on this:

• generated POJOs using JAXB
• analyzed the generated metamodel
• tried to simplify the schema to match the metamodel in the PDF spec (Expression hierarchy).

First of all, from the metamodel perspective the attributes id and typeRef in tChildExpression and tTypedChildExpression are redundant as tExpression already has them. Hence, we can remove tTypedChildExpression and replace it with tChildExpression. I was not able so far to remove tChildExpression. Not an XSD expert, but it seems that the container is needed as there are several children of tExpression type and different names are needed.

@SimonRinguette Could you please try on your side the proposed changes in case I missed something? Could you also send / attach serializations (XML files) for the new constructs so that the group can double check? Thank you.

It would be great if we could simplify the schema :)