Re: Namespaces and XUpdateQueryService

["Timothy M. Dean" <td...@visi.com>]

----- Original Message -----
From: "Kimbro Staken" <ks...@dbxmlgroup.com>
>
> 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 xupdate-dev@xmldb.org
>

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