- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Thu, 20 Dec 2001 16:35:39 +0100
- To: "'Stanislav Vitebskiy'" <svitebskiy@pivotal.com>, w3c-xsl-wg@w3.org, xsl-editors@w3.org
Thanks for the suggestion. We know there's a gap here: if we can ask for just a tiny bit of patience until the XPath 2.0 working draft comes out, I hope you'll like the way the problem has been tackled. Mike Kay > -----Original Message----- > From: Stanislav Vitebskiy [mailto:svitebskiy@pivotal.com] > Sent: 19 December 2001 22:04 > To: w3c-xsl-wg@w3.org; xsl-editors@w3.org > Subject: An XPath function is needed for accessing the filter's parent > context > > > Here is a simple problem: select all the <customer> elements > that have <employee> sibling with the same 'name' attribute. > The solution is pretty obvious: > customer[@name = ../employee/@name] > > Lets now complicate the task a little. Let the name consist of > two parts, 'first-name' and 'last-name'. > Little complication - big problem: the technique shown above > will no longer work; there is no way to compare more than one > attribute of different elements, and there is no workaround in > the current version of XPath. > > My suggestion (it could have been offered before, but I failed > to locate any mention of it) is to add a function that returns > the context against which the filter expression is being > evaluated. The example above can be rewritten like this: > customer[../employee[@name = parent-context()/@name]] > In this case, parent-context() returns the <customer> element > against which <employee> siblings are being checked. > > The advantage of this approach is that it can easily be extended > to comparing multiple attributes/elements/etc. The problem > described in the second paragraph (that XPath 1.0 cannot handle) > can now be solved by this expression: > customer[../employee[ > @first-name = parent-context()/@first-name > and > @last-name = parent-context()/@last-name]] > > > PS., If you think that there is a better way to do it, or that > the current XPath can somehow tackle the problem described > here, please let us all know. >
Received on Thursday, 20 December 2001 10:35:45 UTC