On Fri, 26 Sep 2003 11:46:05 -0400, Terry Rosenbaum wrote: > 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.
Actually I think that it returns Resources (which may be XMLResources). It is possible to have a query that searches other types of documents in the repository (for instance a free text search). > 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? ... I can execute an xpath query on a doc and get a list of attributes back. This should be the same for an xmldb query. > 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). Actually I think the spec implies the opposite and that this is an error. In the case of XPath it is possible to get a list of attributes from the document. It should be the same for and xmlbl xpath query. For example if I have an order-number attribute on a document then I should be able to search on /[EMAIL PROTECTED] = 'foo'[EMAIL PROTECTED] and get all of the order numbers for a customer. > 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. Nope. The spec returns resources not nodes etc. The current implementation builds a doc out of the result, this is our error not a limitation of the spec. > 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. I agree that this is counter to the expectation (in the case of count). The spec is unclear on aggregate operations on results. The current method allows for both single and multiple document counts and allows you to aggregate in your application. This behaviour should be documented though. Where is this not in complience with the spec? > 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)? As I said before I don't believe that the spec does requires results to be xml documents. We should be able to return anything that the quiery langauge can. > I'd be interested in hearing comments from others on this subject. > > Also, I notice that nobody seems to be actively commiting currently. I've been stuck away on other projects. I'm still activly watching and the user list for potential show stoppers. I look like being able to commit more time over the next few weeks. -k.
