[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