On Fri, 26 Sep 2003 21:32:56 -0400, Terry Rosenbaum wrote: >>>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. >> > Yes, correct. My only problem is that we currently have no defined way > to represent that in xindice's results. And, currently it throws an > exception.
This is clearly a bug. To fix it we need to change the internal representation of the query results (and the wire format used by the xml-rpc driver). I understand what is needed here but at the moment I'm looking at namespace indexing and cache issues. >>>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. >> >> > Yes, this is correct. We need a better way to represent the results. See above. At least your questions have spured me into looking at a couple of things. The current cache implementation is pretty dodgy and I'm sure the indexing is not working correctly with namespaced elements. -k.
