If you're viewing the Xalan data model through the DOM APIs, you get a DOM view of the document -- and the DOM does _not_ magically inherit namespace nodes; if they exist at all (they may not, depending on how the DOM was created!) they exist only at the point of declaration. So I'd say the behavior you've described is completely acceptable.
Now: Xalan _also_ has an explicit deviation from the XPath 1.0 standard in how it processes namespace nodes. For efficiency reasons, while we report them as if they were inherited, we don't actually inherit them; instead, we use a DOM-like solution and instantiate them at the point of declaration. This difference is visible through XPath/XSLT only if you try to navigate from a namespace node to its parent, which is an _exceedingly_ rare operation. Our best understanding at this time is that the next iteration of the XPath/XSLT standard will probably change the definition of namespace nodes in such a way that our current behavior will be fully compliant. So we'd rather not sacrifice efficiency to fix the divergence, but instead let XPath come to us. If you're one of the vanishingly small number of users for whom this detail is important, I'm afraid that for now I'd have to advise you to either try another processor... or to consider whether you really want to count on it, given that XPath and XSLT seem to be moving away from it. Yeah, it would make everyone's life easier if the XPath and DOM data models had more closely resembled each other from the beginning...
