- 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>
>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 UTC