It’s a reasonable thing to want, but it goes beyond the remit (and knowledge) of the MDX parser.
Consider:
SELECT { AddCalculatedMembers({[Pay Type].[(All)].Monthly})} DIMENSION PROPERTIES MEMBER_TYPE ON COLUMNS FROM [HR] CELL PROPERTIES CELL_ORDINAL
How is the olap4j parser supposed to know that “Members” should be converted to a Property and “Monthly” should remain as an identifier (so that it can later be resolved to a member)?
Converting .Members to a Property would require knowledge of the set of built-in functions. The olap4j parser deals with syntax, not semantics, so cannot make this kind of change.
An implementation of MdxValidator that had a table of built-in functions could do what you want, but there isn’t one in the olap4j APi.
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While parsing using DefaultMdxParserImpl, why is Members not identified as Function or Property, instead it is identified as IdentifierNode.
MDX
SELECT { AddCalculatedMembers({[Pay Type].[(All)].Members})} DIMENSION PROPERTIES MEMBER_TYPE ON COLUMNS FROM [HR] CELL PROPERTIES CELL_ORDINAL
It’s a reasonable thing to want, but it goes beyond the remit (and knowledge) of the MDX parser.
Consider:
How is the olap4j parser supposed to know that “Members” should be converted to a Property and “Monthly” should remain as an identifier (so that it can later be resolved to a member)?
Converting .Members to a Property would require knowledge of the set of built-in functions. The olap4j parser deals with syntax, not semantics, so cannot make this kind of change.
An implementation of MdxValidator that had a table of built-in functions could do what you want, but there isn’t one in the olap4j APi.
Julian
Thanks Julian for replying. Just a follow up question, Why is then Children identified as property?