[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Numeric top-level predicates in patterns
Let's first agree on some terminology, before I ask the question: Numeric predicates A predicate that has static numeric type, such as [3], [last()], [+@amount], [2.3] Positional predicates A predicate that uses position() or last(), such as [position() > 3] and [@pos = last()] All numeric predicates are also positional predicates. The reverse is not true. Boolean predicates Anything else. Such as [node()], [foo:bar], [3 eq xs:integer(@id)] All positional and numerical predicates are also boolean predicates, the reverse is not true. Top-level predicates A predicate that is not nested, i.e. foo[bar] has a top-level predicate Nested predicates A predicate that is contained within another predicate, such as foo[bar[@id]], here [@id] is the nested predicate. Sibling predicates A predicate that has a preceding predicate, such as foo[a][b], here [b] is a sibling predicate. Apart from positional predicates, I am not sure whether any of these have any official bearing, as in whether they are elswehere defined as such. Now the question. After the discussion on position(), I started wondering about patterns and position. I believe the following is all true (assume they the patterns are placed inside <xsl:template match="XXX">. Selects nothing, ever (not even in a select-expression): foo[2][3] foo[0] bar[last()][2] Redundant [1], always redundant: foo[2][1][1] foo[3][1]/bar[4][1] The rules I am after is, in this order: 1) numerical predicates lower than zero never select anything 2) a sibling numerical predicate that is one is always redundant in a pattern 3) a sibling predicate that is a sibling of a numeric predicate that is higher than one never selects anything Then, to make it tricky, what happens here, if the applied set is //foo? (foo[2])[3] I did not find that well-defined in the spec or in Michael Kay's XSLT 2.0 Programmer's Reference book. The programmer's intended meaning is "for any given foo in the selection, group the second children, take the third". But what it does is "for any second foo, take the third". I believe this behavior is correct (in which case nothing will ever be selected), and the reason it is so, is because of the singleton focus on the current item when the match pattern is applied. The pattern, if applied as an expression in a select-statement, does have merit though and will select the first third foo element that is also a second child. Bottom line is, I think, that creating multiple sibling numerical predicates is (usually) counter-productive and won't match anything when used in a pattern (unless the number is "1", in which case it is also redundant). I do understand what all above patterns are supposed to do, but the point is, is this your understanding of the spec also, and are my "rules" correct or did I miss corner cases? I would like to hear your (anybody's?) thoughts on this and whether I am missing something obvious here. Are multiple sibling numerical predicates indeed useless in (almost) all situations? Do you know of situations where it may have merit? Thanks, Abel Braaksma Exselt XSLT 3.0 processor http://exselt.net
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|