This document contains a list of issues regarding the DOM Level 3 XPath specification Last Call period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before May 1, 2002.
| Id: Title | Status |
|---|---|
| a1 : Reusing the result | agreed |
| a2 : Reusing the result | declined |
| a3 : XPath namespace 2.0 | agreed |
| a4 : XPath namespace | agreed |
| a5 : XPath namespace/xmlns | agreed |
| a6 : context extension | declined |
| a7 : XPathResult 2.0 | agreed |
| a8 : XPathException codes | declined |
| a9 : XPath id() | agreed |
| b1 : conformance rules | agreed |
| b2 : Use of "unsigned" for non-enumeration values | declined |
| b3 : Namespace | agreed |
| b4 : ANY_UNORDERED_NODE_TYPE | agreed |
| b5 : parentNode | declined |
| b6 : prefix and namespaceURI | declined |
| b7 : simplifying XPathEvaluator | declined |
| b8 : createNSResolver | agreed |
| b9 : exception codes | agreed |
| query1 : what should happen when the evaluation of an XPath Expression encounters an entity-node. | declined |
| query2 : what should happen when the evaluation of an XPath Expression encounters an cdata-node. | declined |
| query3 : entity nodes clarification | declined |
| query4 : result types clarification | declined |
| xsl6 : Casting the Document to an XPathEvaluator? | agreed |
| xsl7 : XPathEvaluator.createXPathNSResolver | agreed |
| xsl8 : XPathEvaluator.evaluate() | agreed |
| caro1 : empty nodeset vs. snapshot types | declined |
| caro2 : snapshotItem() of invalid index | declined |
| caro3 : empty nodeset vs. iteration types | declined |
| caro4 : Can XPathResult stringValue ever be null? | declined |
| caro5 : XPathEvaluator.createExpression, XPathEvaluator.createNSResolver, null | declined |
| caro6 : XPathNSResolver: MUST be bound to Node, or not? | declined |
| caro7 : XPathExpression: NSResolver at create time vs. at evaluate time | declined |
| diether1 : createExpression: INVALID_EXPRESSION_ERR | declined |
| diether3 : XPathResultType and XPATHExpression.evaluate | declined |
| diether4 : XPathResult.numberValue | agreed |
| diether5 : string-value | declined |
| diether6 : Issue XPath-25 | declined |
| diether7 : XPathResult | declined |
Description:
At least, I would like to have the wording changed on the description of the result argument. It currently reads:
"The result specifies a specific XPathResult which may be reused and returned by this method. If this is specified as null or the implementation cannot reuse the specified result, a new XPathResult will be constructed and returned."
The problematic part is "cannot reuse" since that implies that implementation must try to reuse the result set even if the implementor knows that reusing the argument is going to be more expensive than creating a fresh result object. The description should be worded so an implementation is completely free to disregard the result argument.
This is clearly the intent of the group that no implementation should be required to reuse the result. The specification has been modified to now say "does not" of "cannot", eliminating any suggestion that the implementation is required to try to reuse the result.
Description:
Hoping that another person who also commented on this method was going to benchmark any difference in performance between reusing a result set and passing null consistently. My instinct is that any performance gain is negligible.
No changes
Description:
It is likely that XPath 2.0 will relax some of the rules concerning namespace nodes. In particular, rules concerning their identity, parentage, and position in document order. These relaxations are designed to make namespace nodes easier to implement without removing any useful functionality. The DOM might consider anticipating these changes, at the very least by a note advising users not to rely on these properties.
Added:
In future versions of the XPath specification, the definition of a namespace node may be changed incompatibly, in which case incompatible changes to field values may be required to implement versions beyond XPath 1.0.
Description:
The specification does not say what methods such as
getNodeName() and getNodeValue()
will return, when applied to a namespace node. I would
expect them to return the name and string-value of the
node as defined in XPath, but since that is not true of
other node types, I might be wrong.
(issue #2)
The DOM group states that "All attributes of Node not described in this section have a null or false value." But, http://www.w3.org/TR/xpath#namespace-nodes states that "The string-value of a namespace node is the namespace URI that is being bound to the namespace prefix". There seems to be a mismatch with the specifications?
The values were clearly specified as null. NodeValue is now specified to return the string value of the XPath namespace node. Also, localName returns the prefix, just the same as prefix. NodeName now returns "#namespace" because there was no other consistent value since localName and prefix are redundant and might be null.
We added: "nodeValue is the same as namespaceURI."
Description:
It might help if the specification spelled out exactly how the set of namespace nodes for an element are derived from information accessible through other DOM interfaces. The different ways namespace information can be represented in DOM (through attributes representing namespace declarations, through namespace URIs on the element and attribute nodes, etc) is a constant source of difficulty. It should also be made explicit that xmlns: attributes will *not* be exposed as attribute nodes through the XPath interface.
(issue #3)
Added:
The set of in-scope namespaces of an element is the default xml namespace combined with the contributions of namespace attributes of the current and all ancester elements. In addition to explicit namespace attributes, any element has an implicit declaration of it's own prefix, if any, or if no prefix then of the default namespace, which is enforced during namespace serialization, fixup, and lookup, which must be added to the set of in-scope namespaces when generating namespace nodes for an element. This causes the set of namespace nodes to be consistent with serialization, fixup, and lookup of namespaces.
Added:
XPath 1.0 does not make available the namespace attributes of an element. The DOM implementation of XPath 1.0 using these defined interfaces never directly returns Attr nodes of namespace attributes, but returned Element nodes still contain them.
Description:
The interface provides only limited ability to set the XPath static and dynamic context. It provides no capabilities to create variables or extension functions, and no way of setting the context position or size. For the typical end-user of the interface, this is not a problem. However, it means that an implementor wishing to provide an XPath engine that is suitable for use, for example, by an XSLT processor, will need to provide additional interfaces, and these will vary from one implementation to another, which will make it more difficult to write an XSLT engine that can work with any DOM implementation.
(issue #1.b)
This request would add too much complexity and we'd like to this module as simple as possible.
Description:
In designing the XPathResult interface, it would be a good idea to anticipate the XPath 2.0 data model. In XPath 2.0, everything is a sequence; it is possible to return a single node, or a sequence of strings. This might suggest separating the notion of result type into two parts (a) is it a singleton or a sequence, (b) what type are the items?
(issue #1.a)
Changed parameters and returns in API to use Object instead of XPathResult.
This permits XPath 2.0 to easily extend this API with a new result object and request types that better represent sequences and other differences between XPath 1.0 and XPath 2.0 results.
The working group will also submit a note to W3C demonstrating how easy it is to extend the API for XPath 2.0 and giving XPath 2.0 experimenters a common starting point (see the last proposal).
Description:
Only two codes are defined for XPathException: invalid expression error, and type error. I couldn't find any definition of these codes. For example, which one should the (incorrect) expression "count(3)" return?
No changes specifically related to these error codes, since the definitions are clearly there in the appropriate place and describe the conditions under which the errors are returned, and already also mentioned the calling of extension functions. Since the description of the error code already refers to conformance, the planned addition of a more-formal conformance section will further improve the understanding of these errors.
Description:
The specification says nothing about the use of the XPath id() function. Does this mean it is always guaranteed to work?
(issue #4)
The specification conformance section now says that the id function produces results consistent with the getElementById function.
Description:
XPath says that it is the job of the host specification to define conformance rules. Where are the conformance rules? For example, is an implementation conformant if it extends the vocabulary of functions that can be called within an XPath expression?
(issue #5)
The specification will now have a conformance section that deals with these things.
Description:
Except when there is need for that extra bit of range, it seems undesirable to make integer arguments or writable attributes that are not enumerations "unsigned". It doesn't matter in Java or JavaScript, since neither supports the concept of unsigned numbers. It does, however, make implementations in other language either fail differently or incorrectly succeed, since C and C++ will transparently convert a negative signed number into a large positive number.
XPathResult.snapshotItem(index) XPathResult.snapshotLength
not really necessary since it is read-only, but for consistency
NodeList in Core is already using
"unsigned". We haven't heard of any problem with this,
therefore we don't think it is necessary to change the
draft.
Description:
Does the resolver argument, from
createExpression() and evaluate()
methods of the XPathEvaluator interface, include
the XML namespace? In other words, will:
evaluator.createExpression('@xml:space', null)
raise a NAMESPACE_ERR? In other specs, the XML
namespace has a special status -- it doesn't have to be
declared explicitly within documents for example -- perhaps
the same special status should extend to here.
The resolver argument , from createExpression() and evaluate() methods of the XpathEvaluator interface, includes the XML namespace - agree. Passing in a NULL will raise a NAMESPACE_ERR.
Description:
The description of
XPathResult.ANY_UNORDERED_NODE_TYPE is ambiguous
- you might be saying that an implementation shouldn't return
the first node in document order, but I don't think that's
what you intend. It would be clearer if you used "might"
instead of "may": "the single node returned might not be the
first in document order". There's similar use of "may" when
you mean "might" throughout, but this one is particularly
ambiguous.
Changed from may to might.
Description:
In the definition of the XPathNamespace interface, there are a few things that are strange for people used to dealing with XPath namespace nodes. The description of XPath namespace nodes says:
"The element is the parent of each of these namespace nodes..."
which implies that the parentNode attribute of XPathNamespace should return the ownerElement (although it would be consistent with the Attr interface, and the Infoset, not to do this).
The DOM Level 3 XPath module is following the infoset data model and must be consistent with attribute nodes, therefore, in DOM, the parent of a namespace node is not it's DOM ownerElement. If it were, the DOM rules related to inserting and removing nodes in a hierarchy would break.
In DOM and XML infoset, a node does not have a parent that it is not a child of. The direction of XPath to be incompatible in this way should not lead to DOM being incompatible with itself.
See also [Issue a3] for compatibility with future versions of XPath.
Description:
Regarding the name:
"A namespace node has an expanded-name: the local part is the namespace prefix (this is empty if the namespace node is for the default namespace); the namespace URI is always null."
This implies that the prefix attribute should be null (since the namespace node is not associated with a namespace through a prefix), that the nodeName should be the prefix of the namespace, and that the namespaceURI should be null.
The XPath definition goes on to say:
"The string-value of a namespace node is the namespace URI that is being bound to the namespace prefix; if it is relative, it must be resolved just like a namespace URI in an expanded-name."
This implies that the nodeValue attribute should be the namespace URI being bound to the namespace prefix rather than null (ref Issue XPath-11).
In particular, I think it's dangerous to give the prefix and namespaceURI attributes different semantics for XPathNamespace nodes to those they have for Element and Attr nodes -- a XPathNamespace node is not *in* a namespace, it *represents* a namespace. If you want to follow the Infoset, then you should define new attributes:
namespaceNodePrefix
namespaceNodeNamespaceURI
rather than reusing 'prefix' and 'namespaceURI' attributes, which do not give access to Infoset properties, but rather are convenience methods for accessing information about the [name] property in the Infoset.
The current proposal is in fact consistent with the Infoset
1.0 data model. prefix and namespace
name are both used in the Infoset and both mapped
the same way they are in Element and Attribute information
item/Interfaces. We don't see any reason to use a
different name when the Infoset does not.
Description:
It seems to me that a very common usage of XPathEvaluator will be to:
Create an XPathNSResolver for a given context node
Evaluate an expression, passing the resolver just created, against the same context node
Since the same object that implements createNSResolver implements evaluate, couldn't we save users a bit of trouble by simplifying this common case?
A proposal:
An alternative signature of evaluate that takes no
'resolver' parameter. The implementation
creates an XPathNSResolver internally
based on the 'contextNode' parameter.
An alternative signature of evaluate that takes no
'contextNode' parameter. The context is
derived from the 'resolver' parameter.
This would mean adding 'contextNode' as a
readonly attribute of XPathNSResolver.
Apart from the rest of these request, if a user only
has an XPathNSResolver interface, it
would be convenient to have a way to get the context
node that the adapter was created from.
Allow the XPathNSResolver parameter to
evaluate to be null without the exception. This
implies that the implementation should again create
it's own resolver from the 'contextNode'
parameter. Granted, this loses the ability to verify
processing of non-namespaced XML. Another alternative
is to use a distinguished instance of
XPathNSResolver to indicate that no
resolver is needed, or that one should be created from
the contextNode parameter, either way.
Already can do this with the XPathEvaluator. Reject their proposal.
Using the context node as a namespace resolver is not considered as an important use case to distinguish in this way. Given that it is possible to use it that way by using createNSResolver(contextNode), we don't think it is necessary to change the current draft.
Description:
What is the lifetime guarantee of the
XPathNSResolver returned by
createNSResolver?
I would assume that it is the same as any
Node. For example, in a reference counting
implementation, holding onto an XPathNSResolver
returned by createNSResolver will keep the whole
Document tree alive.
What are the "liveness" requirements of the XPathNSResolver returned by createNSResolver, with respect to in-scope namespaces?
I would assume that the lookup must be based on the context
node's current position in the tree, not just the state of the
node at createNSResolver time. For example, the
user creates XPathNSResolver fromFoo from the
Element "foo". In separate DOM operations,
Element "foo" is reparented into a different part
of the tree, with different in-scope namespaces. I would
assume that the results of using the
XPathNSResolver would change to reflect the new
namespace scope. Please consider making this explicit in the
spec.
Wording was added in the description of createNSResolver:
"This adapter works like the DOM Level 3 method lookupNamespaceURI on nodes in resolving the namespaceURI from a given prefix using the current information available in the node's hierarchy at the time lookupNamespaceURI is called, also correctly resolving the implicit xml prefix."
Description:
The similarity and overlap between XPathException and DOMException would appear to be problematic. If a caller in a loosely-typed binding received an exception, it would be difficult to distinguish between the exceptions.
The overlap in symbolic names that I've noticed are:
ASException.TYPE_ERR == 2, XPathException.TYPE_ERR == 2
The overlap of code values would seem to be totally avoidable, there is not a shortage of distinct integer values and it should be very easy just to assign, for example, XPathException.TYPE_ERR = 102, so that it will never be misinterpreted as a DOMException.DOMSTRING_SIZE_ERR.
Agreed.
Description:
One (minor) qualm we have is the treatment of (general) entities (which are a DOM-node type, but not an XPath node-type). While it is clear that (a) entity-nodes raise an error if returned (on top level) of a nodeset (b) entity-nodes don't raise an error if "encapsulated" in some returned node. it is unclear what should happen when the evaluation of an XPath Expression encounters an entity-node. Does this raise an error or is it expanded?
The new description of the EntityReference makes clear that entity references are always ignored.
It is obvious that when the entity expansion exists in the hierarchy underneath the entity reference node, that this is the correct behavior, because that causes the proper nodes to be processed consistent with the rest of the DOM.
Where there is no entity expansion, this corresponds to the unexpanded entity reference item. XPath errata make it clear that this information item (and all others not specifically processed by XPath) must be ignored.
Description:
One (minor) qualm we have is the treatment of (general) cdata (which are a DOM-node type, but not an XPath node-type). While it is clear that (a) cdata-nodes raise an error if returned (on top level) of a nodeset (b) cdata-nodes don't raise an error if "encapsulated" in some returned node. it is unclear what should happen when the evaluation of an XPath Expression encounters an cdata-node. Does this raise an error or is it expanded?
In the infoset, there is no node for textual information. There are only character information items. Both the Text node and the CDATA section node of DOM can be seen as a container of character information items. The lack of difference between the two is emphasized by the fact that the CDATA section node derives from the text node. There is no "expansion" involved. They are both virtually-identical containers of character information items. The mapping contained in the spec between DOM text nodes and XPath text nodes makes it clear that the two are treated interchangeably, and when more than one occur in a row, it is no different from other situations where multiple DOM text nodes represent a single XPath text node.
Description:
In Section 1.2 (Mapping DOM to XPath) it may be beneficial to add a small paragraph on entity-nodes (raise an exception whenever they're encountered by an XPath expression).
The new description of the EntityReference makes clear that entity references are always ignored.
It is obvious that when the entity expansion exists in the hierarchy underneath the entity reference node, that this is the correct behavior, because that causes the proper nodes to be processed consistent with the rest of the DOM.
Where there is no entity expansion, this corresponds to the unexpanded entity reference item. XPath errata make it clear that this information item (and all others not specifically processed by XPath) must be ignored.
Description:
The description of result-types may be improved. In particular, a uniform wording may be used for the snapshot semantics of nodetypes "ANY_UNORDERED_NODE_TYPE", ""FIRST_ORDERED_NODE_TYPE", "ORDERED_NODE_SNAPSHOT_TYPE", "UNORDERED_NODE_SNAPSHOT_TYPE", and all simple node types.
The description seems appropriate, and it was suggested by the originator that the issue be closed.
Description:
The "is expected" language in XPathEvaluator is overly vague as to what one can expect from a DOM Implementation that returns true for hasFeature("XPath", "3.0"). If this returns true, can one definitely cast the Document interface to an XPathEvaluator? (We have heard some non-exact information that this may be being fixed already).
The wording was clarified, according to the suggestion:
"The evaluation of XPath expressions is provided by XPathEvaluator. In a DOM implementation which supports the XPath 3.0 feature, as described above, the XPathEvaluator interface will be implemented on the same object which implements the Document interface permitting it to be obtained by the usual binding-specific method such as casting or by using the DOM Level 3 getInterface method. In this case the implementation obtained from the Document supports the XPath DOM module and is compatible with the XPath 1.0 specification."
Description:
Description states "this adapter works by calling the method named lookupNamespacePrefix on Node". This appears to be a typo and should probably be the method named "lookupNamespaceURI". More importantly, this would appear to conflict with previously stated requirement that only DOM Level 2 Core need to be implemented since lookupNamespaceURI is a Level 3 core method. Additionally there appears to be no formal requirement for the nodeResolver that is passed in to be from the same implementation of DOM so it could theoretically even be from a Level 1 DOM. Either a formal requirement for Level 3 DOM needs to be required here or the specification should only hint that "lookupNamespaceURI" can be used in the event that the nodeResolver implements Level 3. If a formal requirement is made, then createNSResolver probably needs to be able to throw an Exception in the event that the requirement is not met.
The wording was changed according to the suggestion:
"This adapter works like the DOM Level 3 method lookupNamespaceURI on nodes in resolving the namespaceURI from a given prefix using the current information available in the node's hierarchy at the time lookupNamespaceURI is called, also correctly resolving the implicit xml prefix."
Description:
In the description of XPathExpression.evaluate(), WRONG_DOCUMENT_ERR, "not supported by the XPathExpression that created this XPathExpression" should probably be "not supported by the XPathEvaluator that created this XPathExpression".
The error was corrected.
Description:
If a snapshot result type is requested, how is an empty nodeset represented? As snapshotLength being 0? As snapshotItem(0) returning null? Both?
There is no need for specific wording. Any place in the DOM APIs that a null is not explicitly permitted as an input or a return, it is forbidden. There is no precedent in DOM for representing an empty list as a null, or any reason to expect that an empty list is an exception to the rule of receiving back a list that has a count of the number of entries, which is also the same way lists work throughout the DOM specification.
Description:
The spec says that an invalid index returns null, yet an index value that is greater than the snapshotLength is always a usage error. Consider throwing an exception for the usage error cases.
There is clear precedence in the DOM APIs for returning null instead of an exception. If the programmer is not paying attention to the bounds of the list, either one will cause an exception.
Description:
If an interation type is requested, how is an empty nodeset represented? By iterateNext() returning null on the first call?
There is no need for specific wording. Any place in the DOM APIs that a null is not explicitly permitted as an input or a return, it is forbidden. There is no precedent in DOM for representing an empty iterator as a null, or any reason to expect that an empty iterator is an exception to the rule of receiving back an iterator that returns null on the first iteration, which is also the same way iterators work throughout the DOM specification.
Description:
None of the functions that return strings in the XPath spec can return null. Nevertheless, the DOM 3 XPath spec should make it clear whether stringValue may ever be null, particularly for those of us who plan to include extensions to the function suite.
There is no need for specific wording. Any place in the DOM APIs that a null is not explicitly permitted as an input or a return, it is forbidden. XPath 1.0 says an object of a type other than the four basic types is converted to a string in a way that is dependent on that type. A string is defined as 0 or more characters, and null is not part of it.
Description:
Can XPathEvaluator.createExpression or XPathEvaluator.createNSResolver return null? If so, under what circumstances?
If they can't, please make this explicit in the spec.
There is no need for specific wording. Any place in the DOM APIs that a null is not explicitly permitted as an input or a return, it is forbidden. None of the other factories within the specification mention that null is not a valid return. Adding it in one place or several places only raises doubt about the meaning of the specification in all places where it is not permitted but would have to be documented to be consistent.
Description:
The specification of XPathEvaluator.createNSResolver seems to suggest that XPathNSResolver implementations must always be bound to some Node, i.e., that they must always work by calling lookupNamespaceURI on some Node. However, Issue XPath-6 seems to hint that users can alternatively create XPathNSResolver implementations from wholecloth, or from whatever they want, include Nodes.
Which is it, MUST be bound to a Node, or users can create any resolver implementation they want and createNSResolver is just a convenience function?
This is properly stated in the description of the interface.
"The XPathNSResolver interface permit prefix strings in the expression to be properly bound to namespaceURI strings. XPathEvaluator can construct an implementation of XPathNSResolver from a node, or the interface may be implemented by any application."
Description:
What is intended by the fact that, for XPathExpression, the XPathNSResolver is specified at XPathExpression creation time, rather than at XPathExpression.evaluate time? We can come up with good reasons to have it either way. Does this suggest that an NSResolver is essential for precomputing an expression (not true in the Xalan-C implementation)? Is it merely convenient to have at precomputation time, or mandatory? Is it intended to be used and discarded by the time the createExpression function returns, or is it kept in the XPathExpression object for later use?
This also touches on previously raised issues about whether the NSResolver must be from the same Document as the XPathEvaluator that creates the expression.
The working group was aware of the difficulty in doing this in a minimal implementation, but the alternative was to prevent the createExpression call from optimizing the resolution of the namespace APIs. This seems consistent with XPath 2.0 which clearly places the namespace resolution into the static context, not into the dynamic context.
Description:
The requirement that XPathEvaluator.createExpression should raise an INVALID_EXPRESSION_ERR if the expression is not legal makes it necessary to test the expression syntax immediately. However, to optimize performance it would be fine to be able to postpone this test when an expression is in fact evaluated by the XPATHExpression.evaluate function. So I suggest to modify XPathEvaluator as follows:
Remove the INVALID_EXPRESSION_ERR from createExpression
Introduce a new function prepare with boolean result. It returns 'true' if the expression is valid, and 'false' otherwise. It may also be used to trigger the calculation of an internal XPath syntax tree (implementation dependant).
Add an INVALID_EXPRESSION_ERR to the XPathExpression.evaluate function.
The working group was aware of the difficulty in doing this in a minimal implementation, but the alternative was to prevent the createExpression call from optimizing the resolution of the namespace APIs. This seems consistent with XPath 2.0 which clearly places the namespace resolution into the static context, not into the dynamic context.
Description:
The use of XPathResultType in the XPATHExpression.evaluate function does not allow maximum optimization in many use cases. For example if an applications wants to use the result of an XPATHExpression.evaluate call in a way that it is not interested in a particular node set, e.g. when it wants to find out whether there is any data at all, it needs only XPath results of type ANY_UNORDERED_NODE_TYPE, BOOLEAN_TYPE, NUMBER_TYPE and STRING_TYPE. Hence, the ANY_TYPE constant is too rough, because the evaluation may then return for example an ORDERED_NODE_SNAPSHOT_TYPE result which is much harder to calculate.
Fortunately, there exists a simple solution: The ANY_TYPE constant should be removed from XPathResultType and the 'type' parameter of the XPATHExpression.evaluate method should be replaced by a 'requestTypes' property which is a set of XPathResultType constants. The evaluated method may then choose to return one of the requested XPathResultTypes and raise a TYPE_ERR if the result cannot be converted to any of the specified types.
The case given is wrong. As the specification says, if you request ANY_TYPE, you will only ever get back ANY_UNORDERED_ITERATOR_TYPE, which is the easiest to compute, and this is about the most efficient way to detect whether there are any results without getting them all. You have to explicitly request the other types to get them.
Description:
The XPath 1.0 spec defines numbers according to IEEE 754. I am not sure whether it is sufficient to fullfil this requirement by simply stating that the numberValue is of type 'double'. Would it not be necessary to use a special IEEE754Number type?
Added text to require the binding to specify further conversion if double does not match IEEE in a particular native binding.
Description:
The XPath 1.0 spec defines a 'string-value' for every node type. It would be useful to add an XPathStringValue property to every Node which allows easy access to a Node's XPath string-value (since 'string-value' is not equivalent to 'textContent').
It could be useful, but there are presently sufficient other methods for obtaining similar results, either requesting a single result as text, using wholeText on a text node, or by calling textContent on an element. It will not be added at this time.
Description:
Issue XPath-25: "Should there be a reset method on the result in case someone wants to iterate the result multiple times?"
It would at least be good to have a 'hasItems' and a 'lookAhead' function to allow simple procedure calls like:
while not myXPathResult.hasItems do myXPathResult:= RequestAnotherXPathResult; SomeCalculation(myXPathResult);
or
if myXPathResult.lookAhead.NodeValue = 'foo' then SomeExtraCalculation(myXPathResult); SomeCalculation(myXPathResult);
Each of these use cases is served better using a snapshot than an iterator.
Description:
The architecture of the XPathResult interface is that of _simulated_ independent interfaces. This becomes obvious on the frequent use of TYPE_ERR exceptions when trying to access its properties. Applications which want to further process XPathResults will have to use hard coded type checking by evaluating the resultType property. This is in particular not elegant when an application uses a library of subroutines to further process a specific type of XPathResult. In this, as I guess, not too seldom use case the subroutine must usualy perform the type checking at run-time at the beginning of the subroutine, in order to test whether it was triggert with the correct type of XPathResult. Therefore, it would be much better for this cases to have different kinds of XPathResult interfaces. Then type checkings could be performed on design time and code debugging would be easier, because type conflicts could instantly be discovered.
A hierarchy of XPathResult interfaces could look like this:
A. Abstract interfaces:
interface XPathResult {
readonly attribute short resultType;
};
interface XPathSingleNodeResult: TdomXPathResult {
readonly attribute Node singleNodeValue;
};
interface XPathIteratorResult : XPathResult {
readonly attribute boolean invalidIteratorState;
readonly attribute integer iteratorLength;
Node iterateNext();
};
interface XPathSnapshotResult : XPathResult {
readonly attribute integer snapshotLength;
Node snapshotItem(in integer index);
};B. Concrete Interfaces:
interface XPathBooleanResult : XPathResult {
readonly attribute boolean booleanValue;
};
interface XPathNumberResult : XPathResult {
readonly attribute double numberValue;
};
interface XPathStringResult : XPathResult {
readonly attribute DOMString stringValue;
};
interface XPathAnyUnorderedNodeResult : XPathSingleNodeResult;
interface XPathFirstOrderedNodeResult : XPathSingleNodeResult;
interface XPathOrderedNodeIteratorResult : XPathIteratorResult;
interface XPathUnorderedNodeIteratorResult : XPathIteratorResult;
interface XPathOrderedNodeSnapshotResult : XPathSnapshotResult;
interface XPathUnorderedNodeSnapshotResult : XPathSnapshotResult;
This approach of multiple returned object types was considered several times and rejected by the working group in favor of the present design which uses a single return object to implement all current result types.
Last update: $Date: 2003/03/26 16:32:54 $