> -----Original Message----- > From: Kimbro Staken [mailto:[EMAIL PROTECTED] > Ok, let's see what it looks like and then we can probably change the > interface itself. >
CVS Patch coming soon!! > > My opinion is the opposite. I see it as the namespace methods > being the > thing used closest to execution time so they should override the XML > declared namespaces. Think about the XUpdate being stored on > disk and then > being brought into the program. In that scenario I'd > definitely expect the > methods to override. Also if you're programmatically generating the > XUpdate, then you're probably not going to use both mechanisms anyway. > Yeah, as I was getting into the implementation I came to the same conclusion, reversing my original assumption. Here's a summary of all the changes I have made: The CVS patch will be coming very shortly. Changes To Lexus Code: ====================== 1) Modified SAX-based parsing of XUpdate query string to store namespace mappings from query string into a HashMap of prefix-to-URI mappings 2) Modified XUpdate query implementation class to make HashMap of namespace mappings accessible via a protected instance variable Changes To XIndice Code: ======================== 1) Modified XUpdateQueryService implementation to contain the same namespace-setting methods already available in the XPathQueryService implementation. Code was copied and pasted from one class to the other: It might make sense to refactor into a common base class, but I decided to not go that far until it is agreed that this functionality be made part of the spec. 2) Modified XUpdate query implementation to account for repacked classes in Lexus code 3) Modified XUpdate query implementation to accept namespaces passed via client API as well as namespaces defined within XUpdate query. Current implementation assumes that API-defined namespace mappings take precedence, but this could be easily changed via a single boolean constant definition, or even made configurable if desired. 4) Modified NamespaceMap class to implement a convenience method for copying one map's contents into another. I've got all these changes tested and working within my environment. There are a couple of limitations remaining: 1) Defining namespaces via a default NS mapping still do not work: This is true when using the namespace APIs and also when specifying a default namespace within the XUpdate query string. I haven't yet looked into this problem seriously, but I suspect that it might be within the Xalan code's DefaultPrefixResolver class. This might also be causing some of the problems I've seen when using default namespaces with simple XML queries. 2) The current implementation is pretty dumb when handling namespace definitions within the XUpdate query string. It does not attempt to push/pop NS mappings based on which XML elements of the query string they are defined in. As a result, any NS definitions within the XUpdate query string will be defined globally for the entire query. If duplicate NS mappings are defined at different levels within the XUpdate query XML, then the last defined mapping will take precendence. I'll submit the CVS patches (one for Lexus, one for XIndice) within the next couple of hours. - Tim
