> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kimbro Staken > Sent: Thursday, December 13, 2001 1:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Namespaces and XUpdateQueryService > > > It seems likely this is a bug in Lexus, but I haven't looked at it in > detail. Lars, do you know if namespaces work correctly in > Lexus? If they > do then it's a bug in Xindice (what used to be dbXML for > those who don't > know).
I've got further information on this issue - I still can't figure out how to test exactly what Lexus supports or not, but I've done a lot of poking around in the code as well as trying out Xindice with some modified code to see what happens. There are 2 primary things that I've been able to verify: 1) Updates that require a namespace in their select attribute *will not* work when querying against an entire collection rather than an individual resource. This is because of the Xindice implementation in the XUpdateImpl class, in the org.apache.xindice.core.xupdate package. When executing a query against a collection it basically invokes the Xindice XPath query service's code to first select all pertinent documents. This method depends on a namespace map being set as it is when using the setNamespace() methods of the XPathQueryService service. Because this is used within the implementation of the XUpdate service (which has no such mapping defined), the XPath query method is passed with a null value for its namespace map, and will result in no documents being selected from the collection. 2) When querying against a single resource, namespace-aware selects can be made to work. However, there is an oddity with how namespace prefixes must be specified. I had assumed (and previous replies on this list have verified) that the intended behavior is for the namespace prefix(es) used in a select attribute would be resolve by looking for "xmlns:" declarations elswhere in the XUpdate <modifications> element. This does not appear to be the case with the current implementation. Instead, prefixes from the select attribute are resolved against the "xmlns:" declarations *in the target XML document*. In other words, using an attribute as in the following example: <xupdate:modifications> <xupdate:append select="/myns:MyElement"> ... </xupdate:append> </xupdate:modifications> will only work if the "myns" namespace prefix is used in the document(s) being modified. It does not appear possible to use a different namespace prefix in the XUpdate modification commands than is used in the actual document being modified. Also, I have been unable to update any document which declare their elements using a default namespace rather than an explicit prefix. I have traced the root of this "feature" to how the Xalan XPathQuery is set up. A prefix resolver is passed into the query object - That resolver is an instance of the PrefixResolverDefault class, and it uses the current context node from the target document. This is different than what is done in the XPathQueryService's implementation, which sets up a special "context node" to use with its resolver based on the namespace map. With these two discoveries in mind, I am left with several problems when trying to update my documents that have namespaces. First of all, the lack of setNamespace() methods within the XUpdateQueryService makes it really inconsistent with how I must use the XPathQueryService. It also makes it more difficult for me to programatically build up my XUpdate query strings. Secondly, my documents are currently stored using default namespaces, so I cannot select them for updates without manually modifying them to use an explitly prefixed namespace: I have only a few documents right now so this is possible, but it will be tedious and annoying. Thirdly, I cannot perform an XUpdate query on a collection of documents that use namespaces, only on individual resources. Fourthly, I am forced to use the same namespace prefixes in my XUpdate query strings that are used within my database documents - This seems inherently wrong because I should be able to use any namespaces I choose so long as they map to the same URI that is used in my database documents. I am in the process of making some Xindice code changes that will make my life a lot easier - I've made some progress and I hope to be able to get all of my problems fixed. I will gladly submit any enhancements I make to the open source project, if the rest of the community feels that my enhancements are the right thing to do. The following is a list of enhancements that I intend to make - If there is anyone already working on this please let me know. Also, if there is any advice/recommendations that people would like to make to help guide my direction, I welcome further discussion on any of these issues. Here is what I am planning to do: 1) I will copy the setNamespace() and related methods from the XPathQueryService to the XUpdateQueryService. Because this is not currently in the XUpdate service spec (and may never be), I will make my changes only in the Xindice implementation of the service and use appropriate casting in my code to avoid making the assumption that this would be part of the XUpdateSpec. This change will address the inconsistencies and programmatic limitations I'm having when making updating namespaced documents. 2) I will modify the XUpdate service's server-side implementation to pass the appropriate namespace maps into the XPath query code. This should address the problems I've encountered when trying to update against an entire collection rather than an individual resource. 3) I will attempt to modify how namespace prefixes are resolved so that namespace declarations *within the XUpdate <modifications> XML* will be used rather than the declarations within the target document(s). This change may be within Xindice code or it could be in the Lexus code. I'm not sure how to go about getting the latest Lexus code, or how to submit changes if it becomes necessary to do so: Any advice on how to proceed with possible changes in Lexus code would be appreciated. Thanks in advance for any advice you can give, and I would love it if there were some discussion on these issues so that I can make my enhancements more useful to the rest of the Apache community. - Tim ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------