Proposal for Extended Element and Attribute Tests #13
Conversation
There was a problem hiding this comment.
An alternative I have been thinking about is to allow arbitrary predicates to be added to an ItemType. For example xs:integer[. = 1 to 100] or element()[self::ol|self::ul]. This seems a more powerful capability that subsumes the extensions being proposed here (and perhaps involves less new grammar). There are potential difficulties with circularity; we might need a rule that restricts the ability of the predicate to refer to user-defined variables or functions.
|
@rhdunn I like your proposal, it seems quite a simple addition to me. @michaelhkay Your counter suggestion is interesting indeed. The problem I see with adding predicates like that to type tests, is that it is potentially a lot of work for some implementations to support them, but I am not opposed to seeing the idea developed further. |
|
The thing I would be primarily interested in is the possibility to use predicates in the case operands of the typeswitch expression. There, I am convinced, they would be very useful and significantly increase the power of XQuery for recursive processing of source trees. As the typeswitch expression already extended the use of sequence types by their union, I can imagine that a further extension introducing predicates would also be an option, should the general extension of sequence types by predicates turn out to be a too heavy weight. Apart from this, I never understood why sequence types to not support partial wildcards and would greet such an extension very much. |
|
@michaelhkay I also like your predicate type syntax. It would be worth creating a separate proposal to allow it to be discussed further. |
|
This can be achieved by making use of |
Allows element and attribute tests to support union and wildcard name tests to match the functionality of path expressions.