[Phoenix] Proposal for a new locationPath implementation
Andreas Wuest
awuest at student.ethz.ch
Fri Sep 22 22:41:06 CEST 2006
Hi
First, let me recap what a location path is: a location path is a means
for uniquely identifying nodes in an XML document, which is robust with
regard to intermediate XSL transformations.
In our case, we would like to be able to construct an XPath query from a
location path in order to retrieve the in-core representation of that
node (i.e. the nsIDOMNode object).
But nobody says that the location path must actually *be* an XPath
expression. We only must be able to *construct* an XPath query from such
a representation.
And this is my proposed format of the location path: it should still be
XPath query like, but we substitute the namespace prefixes in the path
by the actual namespaces. E.g.
"a:foo/b:bar/c:duck/d:quack/text()"
would become
"{foo.org}:foo/{bar.org}:bar/{rubberducky.com}:duck/{rubberducky.com}:quack/text()"
From this representation, we construct a custom namespace resolver
which would be the functional equivalent of:
function nsResolver(aPrefix) {
switch (aPrefix) {
case "ns0":
return "foo.org";
case "ns1":
return "bar.org";
case "ns2":
return "rubberducky.com";
default:
return null;
}
}
We can then issue the XPath query as
"ns0:foo/ns1:bar/ns2:duck/ns2:quack/text()".
I *believe* that this would resolve all four constraints mentioned in
http://wyona.com/pipermail/phoenix/2006-September/000665.html.
It is now your job to either prove me wrong or to point out that this
approach can't be implemented due to the shortcomings of XSLT. ;)
--
Kind regards,
Andi
More information about the Phoenix
mailing list