----- Original Message ----- From: "Kimbro Staken" <[EMAIL PROTECTED]> > > On Wednesday, December 19, 2001, at 12:11 PM, Timothy M. Dean wrote: > > > > 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: > > Fixes for these things would be happily accepted. >
I'm new to this "open source" thing ;) Can anyone tell me what precisely I should be doing to submit my code changes? Do I simply do a CVS commit, or are there additional/alternate steps that I should be following? > > 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. > > > > You're probably right that this is cleaner and it's definitely more > consistent. For now we can incorporate the methods in Xindice and then > change the interface in the next update. Let's use Xindice as a prototype > to see how this works. I've completed these changes and gotten them tested so they work in my specific environment. The changes I made to the client side are completely within the Xindice XUpdateQueryServiceImpl class. In order to make use of them it is necessary to cast the more generic XUpdateQueryService instance to the Xindice-specific implementation. > > > 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. > > > > This would be great. > These changes are also completed. Namespace maps that were defined by the client API are being passed through to both the XPath implementation when updating against a collection, and to the Lexus implementation when updating against a single 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. > > > > This will almost certainly be in the Lexus code. If you can get CVS and > make some patches send them to [EMAIL PROTECTED] > This part has yet to be completed. I will try to get the latest Lexus code as soon as I am able and work on this change. Before I get too far along - An opinion question: Assuming that an XAPI client application specifies one or more namespaces via the setNamespace() method, and assuming that namespace mappings are also defined within the XUpdate commands XML, which namespace mappings should be given priority if the same namespace prefix is mapped in two places? I am assuming that any namespaces that are defined within the XUpdate modifications XML should take precedence over any mappings defined by the API client - Any other opinions on this? - Tim
