DOM Level 3 XPath JavaScript Binding

The W3C DOM XPath Specification is a great way to apply XPath queries to DOM documents.

However, although formally correct, it appears cumbersome and awkward when implemented in JavaScript.

Providing an XPath expression's evaluation result by means of five distinct properties/methods, of which always only one is valid, doesn't seem an ideal approach, particularly not when JavaScript's strengths come into play, permitting any type of result to be returned by a function call or variable.

One of the more outstanding JavaScript features so far is that JavaScript is an untyped language. Whilst this is a valid assertion, segregating return values into type-aware constructs like "booleanValue", "numberValue" etc. is basically unneccessary and redundant.

Morover, iterators like "iterateNodes()", or "snapShotItem()", are inconvenient constructs not perpetuated in JavaScipt. Accessing collections by means of Array-like objects is a considerably more convenient and less ponderous approach.

Astonishingly, the W3C's JavaScript binding so far perpetuates the W3C DOM XPath Specification just like it is… "1:1". But they didn't take the step ahead to reflect the specification's formal, language-independant, intention and to amend it into a well-designed JavaScript construct.


Well, many roads lead to Rome. And, sure, implementing it this way is one possible way… However, I'd like to suggest a different pattern, describing a significantly shorter way.

My below-mentioned pattern alleviates the overhead for using XPath down to the essential. It's efficient and comfortable. At the same time it retains the full existing plethora of XPath usability.

I suggest the following pattern to get adapted by the W3C, becoming a standard client-site JavaScript construct:


http://www.dashop.de/blog/en/dev/JavaScript/content/XPath/JavaScript-XPath-Implementation.html


Axel Dahmen
www.axeldahmen.de

Received on Monday, 19 April 2010 05:29:10 UTC