Re: Namespace problem after Processing DOM input with Xalan.

[Da...@lotus.com]

Ainsley Burdett writes:
>I have a problem with loosing [sic] namespace information from the
>DOM structure after XSL processing....In this case the DOM is styled
>with Xalan [and] then any nodes from the i18n namespace are replaced
>with internationalised text or data....
 [detailed steps follow]
>4) However instead of outputting this I process it by using a
>NodeIteratorImpl object, looking only for nodes with the prefix 'i18n'
>in order to do some post processing. According the iterator there are
>no such nodes.

I think this could be the problem. Can you re-think this so that your
goal is to look for nodes whose namespace URI is the correct one,
instead of focusing on the prefix? That line of thinking might lead
you to a good solution.
.................David Marston

Re: Namespace problem after Processing DOM input with Xalan.

[Gary L Peskin <ga...@firstech.com>]

David_Marston@lotus.com wrote:
> 
> Ainsley Burdett writes:
> >I have a problem with loosing [sic] namespace information from the
> >DOM structure after XSL processing....In this case the DOM is styled
> >with Xalan [and] then any nodes from the i18n namespace are replaced
> >with internationalised text or data....
>  [detailed steps follow]
> >4) However instead of outputting this I process it by using a
> >NodeIteratorImpl object, looking only for nodes with the prefix 'i18n'
> >in order to do some post processing. According the iterator there are
> >no such nodes.
> 
> I think this could be the problem. Can you re-think this so that your
> goal is to look for nodes whose namespace URI is the correct one,
> instead of focusing on the prefix? That line of thinking might lead
> you to a good solution.
> .................David Marston

Ainsley --

This gets uglier.  David and Joe are correct in that the prefix is not
really useful in this situation since the namespace is really
represented by the URI and any prefix or multiple prefixes can be used.

Having said that, the problem with XalanJ1 is that 
org.apache.xalan.xpath.xml.FormatterToDOM.startElement() always does a
org.w3c.dom.Document.createElement(), which is namespace ignorant, even
though it should be doing an org.w3c.dom.Document.createElementNS() when
a namespace is involved.  This means that XalanJ1 is creating a node
called i18n:text with an attribute xmlns:i18n="...".  These are _not_
nodes with namespaces.  So, to fix this, we'd have to fix FormatterToDOM
to be namespace aware, assuming that the DOM Document implementation
also supports namespaces.

I'm not sure that this work makes sense given that XalanJ1 is to be
replaced eventually by XalanJ2.  Scott or Myriam, do you have any
feelings for whether it makes sense to make this fix to XalanJ1??

As a temporary workaround, you could replace the line

  String namespace = n.getPrefix();

in I18NNodeFilter.acceptNode() with

  String namespace;
  String fullName = n.getNodeName();
  int colonPos = fullName.indexOf(':');
  if (colonPos == -1)
    namespace = null;
  else
    namespace = fullName.substring(0, colonPos);

You are cautioned however that:
-- This does not really obtain the namespace, which is the URI, just the
prefix that happened to be selected for this Node.
-- This behavior may change if a DOM implementation other than the
current version of Xerces is used to create the DOM.
-- This behavior almost certainly will change with new versions of
XalanJ.
-- This behavior may change if this bug is fixed in XalanJ1.

Gary