Kevin O'Neill wrote:
So I'm back doing some work with xindice and I've come across a couple of
issues with regards to query results.

Namespace searches work the appropriate nodes are selected. The problem is
that the namespace declarations are missing from the returned elements.
For example if you store a document

<a xmlns="example.com">
  <b>foo</b>
</a>

then query /x:a/x:b (with x mapped to "example.com")

<b>foo</b> will be returned and the namespace of b is lost.

This is obviously a bigger issue than simply querying within Xindice, as it has more to do with XML Namespaces and default attributes. Generally when you do a query absent any care over XML Namespace, you already know the namespace. Because 'xmlns' is merely from the XML 1.0 POV a default attribute, you wouldn't necessarily want all the defaulted attributes to be present on a query result (e.g., some HTML elements have quite a few). 'xmlns' is a *bit* different than other attributes and I wouldn't be surprised to see implementations vary in their handling of it.

I'm not sure I'd consider that the 'xmlns' was "lost", as it's not
(as above) really a normal attribute. By extension, if you queried
and returned a large XML document, you'd not want 'xmlns' attributes
on *all* the returned elements (I wouldn't think).

The real answer to this problem is probably fairly elusive as handling
of 'xmlns' has historically been pretty murky.

You might try this with explicit prefixes and a short DTD to see if
you get the results you want.

> Store the following:
>
> <n:a xmlns:n="example.com">
>   <n:b>foo</n:b>
> </n:a>
>
> then query /x:a/x:b (with x mapped to "example.com")
>
> <n:b>foo</n:b> will be returned. Calling getContentAsDOM() on the
> XMLResource returned throw an exception indicating that the prefix n has
> not been declared.
>
> There's also an issue if the result is not an element as CollectionImpl in
> the embeded database attempts to cast the resulting node to an Element.
> This is wasy to avoid by checking the type of the node before casting it.
>
> I'm a little unsure of how to handle the issue of the namespaces for the
> element. Any ideas?

Again, I'd try this with a short DTD and explicit attributes to see if
your results improve, say, something like:

 <!DOCTYPE n:a [
   <!ELEMENT n:a ( n:b )* >
   <!ATTLIST n:a
      xmlns:n   CDATA   #FIXED  "http://example.com/";
   >
   <!ELEMENT n:b ( PCDATA )* >
   <!ATTLIST n:b
      xmlns:n   CDATA   #FIXED  "http://example.com/";
   >
 ]>
 <n:a xmlns:n="http://example.com/";>
   <n:b xmlns:n="http://example.com/";>foo</n:b>
 </n:a>


Murray

...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

          "The current and future international political
           environment severely constrains this country's
           ability to conduct long-range strike missions." -- DARPA
           http://news.bbc.co.uk/1/hi/world/americas/3035332.stm



Reply via email to