"Resources returned by the XPathQueryService SHOULD contain an ID to the source
document within the collection if the XPath query resolves to the root
node of a Resource matching the query." (Better would be MUST instead
of SHOULD, of course, but we haven't got enough input on that, yet.
Maybe the vote helps.) The documentation should include a caveat on
using the IDs: Implementations may not be able to return IDs and the
user should know the difference between a Resource and a part of a
Resource (defined by a subnode).
The concern I have with this is that the implementation will have to check whether a result is a root of the document or not to be able to set the ID.
To me this seems to remove one of the real benefits of setting the ID in that it could be used to get back to the containing document regardless of the returned node. I'd prefer to set the ID on all resources returned so that you have an easy way to get back to the full containing document. The concern is whether that is confusing to users or not. Users may (likely will) think the ID is that of the node rather then the document.
Perhaps adding a getDocumentID() method to resource would be a solution. For resources that are documents getID() and getDocumentID() return the same thing. For resources that are the result of a query getID() returns null and getDocumentID() returns the ID for the containing document or null if there is no containing document.
Kimbro Staken The dbXML Project htttp://www.dbxml.org ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
