- From: Philippe Le Hegaret <plh@w3.org>
- Date: 28 Aug 2003 15:05:37 -0400
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: WWW DOM <www-dom@w3.org>
On Fri, 2003-08-01 at 00:04, Curt Arnold wrote: > As mentioned in a previous message, the correspondence between the > DocumentPosition bits and XPath axes is unclear and use different names > (CONTAINED_BY vs Ancestor, for example) for the same concept. > > I would think that Node.compareDocumentPosition would be very prone to > usage errors. Most scripting languages would not provide symbolic > constants and it would be relatively easy to misuse bit-wise operators. > > It would seem a whole lot simplier and more usable to provide boolean > methods that correspond to the XPath Axes, > > boolean isChild(Node node); > boolean isDescendant(Node node); > boolean isParent(Node node); > boolean isAncestor(Node node); > boolean isFollowingSibling(Node node); // always false for attribute > boolean isPrecedingSibling(Node node); // always false for attributes > boolean isSibling(Node node); > boolean isFollowing(Node node); > boolean isPreceding(Node node); > boolean isAttribute(Node node); > > Plus the existing isSame(Node node) for the self axis. > descendant-or-self and ancestor-or-self could be handled by or'ing > isSame and the appropriate other axis test. > > Adding a method to determine if the nodes are in the same document might > also be helpful. > > If you are only interested if the particular pair are, for example, > parent and child, it should be more efficient to only check that instead > of figuring out how they are related. The addition of several methods in order to achieve the current functionality of compareDocumentPosition doesn't really encourage to change the current proposal, especially since it is easier to add a new constant than a new method if future extensions. So we still prefer the current proposal in the specification... Philippe
Received on Thursday, 28 August 2003 15:08:49 UTC