[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Abel,
you wrote:
OK, so I could (as well) use this expression for the "negative case", or stick with the easiest understandable variant, like David suggested:
not(every $child in * satisfies $child[@my_attribute])
Thank you very much for this hint - I actually need a test that returns true if all children carry the attribute AND if there are element children at all - maybe David's suggestion might help? (See below.)
David,
you wrote:
Not bad either. Could I even use this expression to return false when there are no element children at all? Or would I have to make this an additional condition?
Nice and neat.
Like I (partially) wrote, I prefer to leave the condition equalling this third case implied in my xsl:otherwise clause, while explicitly testing for the other two cases using xsl:when.
I am grateful to both of you for your precise explanations.
Yves
P.S.: It seems that in XSLT just as well as in life, being negative often is much easier than being positive. :-)
Re: [xsl] Universally quantified test of child attribute presence/absence
Subject: Re: [xsl] Universally quantified test of child attribute presence/absence From: Yves Forkl <Y.Forkl@xxxxxx> Date: Tue, 20 Mar 2007 14:07:49 +0100 |
Abel,
you wrote:
The expression:
empty(*/@my_attribute)
will return true() when there is no child that has an attribute @my_attribute (i.e., in other words, it will return true when the expression returns an empty sequence).
OK, so I could (as well) use this expression for the "negative case", or stick with the easiest understandable variant, like David suggested:
not(every $child in * satisfies $child[@my_attribute])
The expression:
every $child in * satisfies $child/@my_attribute
may not return the expected answer when there are no childs at all: it will return true. [...]
Thank you very much for this hint - I actually need a test that returns true if all children carry the attribute AND if there are element children at all - maybe David's suggestion might help? (See below.)
David,
you wrote:
> Personally I'd have probably written the "positive test" in negative > form, rather than saying every chiuld has teh attribute, say no child > doesn't have the attribute > not(*[not(@my_attribute)])
Not bad either. Could I even use this expression to return false when there are no element children at all? Or would I have to make this an additional condition?
> which is also valid xpath 1 of course. > This would make your "negative" test > exists(*[not(@my_attribute)]
Nice and neat.
> the tests you show test that all the elements have or dont have the > attribute, but only test for one or the other, they don't test for the > mixed case. > The most direct test for the mixed test is just to test > test="*[@my_attribute] and *[not(@my_attribute)]"
Like I (partially) wrote, I prefer to leave the condition equalling this third case implied in my xsl:otherwise clause, while explicitly testing for the other two cases using xsl:when.
I am grateful to both of you for your precise explanations.
Yves
P.S.: It seems that in XSLT just as well as in life, being negative often is much easier than being positive. :-)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Universally quantified te, Abel Braaksma | Thread | Re: [xsl] Universally quantified te, David Carlisle |
Re: [xsl] Universally quantified te, Abel Braaksma | Date | Re: [xsl] Universally quantified te, David Carlisle |
Month |