> -----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/
----------------------------------------------------------------------
