Hi,
I'm currently working on this issue.
From the bugzilla report:
--------------------- 22156 ---------------------
/XPath queries in the form //foo/@bar fail due to the way that result sets are/
/created. /
/I've added unit tests that expose the issue./
/------- Additional Comments From Kevin O'Neill <mailto:[EMAIL PROTECTED]> 2003-08-09 03:43 -------/
/This has been partially fixed. I'm unsure though if a collection should be seen
as a virtual document for these types of functions. The current solution
provides a result from each document.
/--------------------- 22156 ---------------------
/
/The original intent of the XML:DB API and xindice's implementation
of it was that ALL queries returned XML.
In cases where the XPATH did not yield a nodeset as a result, the query was just incorrect.
I believe that this intent was with good reason.
Consider the "attribute selection" case. While it would be possible to convert an XPATH query result of a nodeset containing a single attribute to a string (containing the attribute's value, or perhaps including both the attribute name and value e.g. "foo='bar'"), this idea would fall apart if the XPATH result nodeset contained multiple attributes. How does one represent a set of multiple attribute nodes as a String? Concatenate the values? Build a comma-separated list of values? ...
Therefore, I believe that the wise thing to do is to follow the original intent of XML:DB and return the containing node whenever an attribute node is encountered in the XPATH result. (Currently an exception occurs when trying to add the attribute as a child of the root in the result document).
I think to do otherwise would necessitate extension of the XML:DB spec. to include some means of representing query results that were not nodesets containing elements. I realize that people want some way to "just select attribute values", but without some spec guiding how such results are to be returned, I do not feel it is wise to attempt to incorporate such functionality into xindice.
With regard to "return types other than nodesets" (e.g. XPath produces String or boolean results), I wonder about the usefulness of this. Users might expect that, e.g. "count(//[EMAIL PROTECTED]'Dave']) would return a count of persons named Dave in the collection. What would actually be returned is a count for each selected document. This may be counter-intuitive. The example "count" behavior is currently implemented. Similarly, behavior is currently implemented for boolean(//[EMAIL PROTECTED]'Dave']) returning 'true' for each document in the collection containing a person named Dave. Note that the Resources returned by the query in each case are simply text strings (not XML as required by XML:DB). I'm not saying that this behavior is necessarily bad, but it is definitely not in compliance with the spec, and I do question the usefulness of it.
Would it not be better to stick to the XML:DB spec and require that all queries return XML (at least until such time as the spec defines a way to do otherwise)?
I'd be interested in hearing comments from others on this subject.
Also, I notice that nobody seems to be actively commiting currently.
I'd like to work on this issue, some of the current bugs, and other things. Can I get any support for gaining commit access? (I would not change the behavior for "non-element" results as implemented by Kevin recently unless there was a consensus that it should be changed. I would like to fix the bug in handling of attribute element selection should I be able to gain consensus as to preference on how to handle it (return container vs. return attribute value)).
-Terry
