W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: generating XPath expression from Node for DOM L3 XPath

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Wed, 18 Jul 2001 14:20:18 -0400
To: "'www-dom@w3.org'" <www-dom@w3.org>
Message-ID: <OF7169258E.E5CBB7D7-ON85256A8D.0063B320@pok.ibm.com>

>As a complement to DOM XPath allowing you to determine a NodeSet from an
>XPath expression, it seems like it might be useful to provide a mechanism
to
>determine a XPath expression from a node.

I agree with the observation that most XPath implementations should
probably come with XPath generator utilities.

But it may be unclear whether it really should be a DOM API as opposed to a
utility running on top of the DOM APIs. Unlike XPath, where we have all the
incrementality/invalidation concerns, this might want to be a
run-it-once-and-get-a-string operation.

>it would be left up to the individual implementor to choose the algorithm
to
>build the XPath

Testability would be awful, and portability would be bad if folk make
assumptions about the quality of the XPath generated (eg, how likely it is
to be broken by trivial document mutation -- city[2] is likely to be a lot
stronger than the more generic "fifth child", for example, even if both
were valid when they were calculated).

If you really want to allow that variability in the generated paths, I'd
consider that a good reason _not_ to adopt it into the DOM. That way, you
could independently select/configure the implementation(s) which generated
paths that met your application's needs.

If the behavior isn't standardized, that's often a hint that the API
shouldn't be either. Half a contract is generally just enough to hang
yourself with.

______________________________________
Joe Kesselman  / IBM Research
Received on Thursday, 19 July 2001 01:39:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT