@oowekyala and @adangel , do you know whether the root cause for this is:

1. The Jorje AST not exposing it
2. Our AST Wrapper not exposing it
3. The Designer not exposing it

I guess depending on the answer the effort to fix it dramatically changes.

I had a look into this. On the Java side, we have access to the implemented interfaces:

But this getter is not exposed as a node attribute in XPath (in contrary to @SuperClassName, which is exposed as a simple attribute).

The reason is, that this is a List. At some time, we decided to not implement this (see #2451), because there was no use case. Now it seems, we have a use case? (Of course, you can write a Java-based rule instead of a XPath rule).

Implementing support for List/Collections seems to be in general a useful thing. I don't know however, how feasible this is, because of this quote: "attributes [in newer Saxon versions] are supposed to be always non-sequences.". This maybe has something to do with how Saxon tries to optimize the XPath expression - and if an attribute can be a sequence or a non-sequence optimization is probably harder.

So, someone needs to investigate, whether the claim, that attributes must be non-sequences is still valid. But it might very well be impossible to just return a list for an attribute: XPath operates on XML, and in XML attributes are simple values and not sequences. And the underlying model, we create for Saxon, so that it can execute the XPath expression, probably should mimic a valid XML model.

As described in the mentioned issue, one way could be to create custom xpath functions, whenever we want to have access to a list of things...

See also #4950