Hi Elisheva,
the error on compilation is correct, since this is a bad-practice in DMN: in DMN you are expected to define an ItemDefinition for your InputData nodes, so while building the decision-logic of the several DRG elements the compiler can verify the expressions are valid, statically.
In this case, since the ItemDefinition seems to be missing for 'X', the compiler cannot know for certain that property 'y' exists while accessing it with 'X.y'.
I would expect similarly it would happen for 'Z' if an ItemDefinition is not defined.
That said, you can define your InputData as having the type FEEL:Any.
In this case, this is an indication to the compiler that say the InputData node 'X' as a generic ~"top type", hence the compiler would not emit an error if accessing 'X.a' since it's considered valid as explicitly given the Any type.
However naturally, this may break at run-time as this is in fact just circumventing type checking at compile-time, and iterating on the DMN bad-practice mentioned above.
I tested this locally and seems to me it would work for your sample.
I hope this clarifies and helps!
MM