Re: [C1 AND C2] Explanation of Redundant Namespace Prefixes

[Davanum Srinivas <di...@yahoo.com>]

Scott, Xalan2J-Team,

What's your position on the problem described below? Can we have a switch 
("setFeature/getFeature") to be able to preserve namespaces in Xalan2J? It's a big overhead if we
have to do it in C2 and other general users might need it too?

Thanks,
dims

--- Robin Green <gr...@hotmail.com> wrote:
> "Per Kreipke" <pe...@onclave.com> wrote:
> >Ok, so the bug isn't in the esql taglib, the extra namespace attributes are
> >coming from the xsp processor itself, in xsp-java.xsl. The following block
> >adds the code that generates the namespace attributes:
> >
> >     <!-- Add namespace declarations -->
> >     <xsl:for-each select="namespace::*">
> >       ((Element) xspCurrentNode).setAttribute(
> >         "xmlns:<xsl:value-of select="local-name(.)"/>",
> >         "<xsl:value-of select="."/>"
> >       );
> >     </xsl:for-each>
> >
> >I still don't think the objects shown below need namespace declarations on
> >each of them. Where are the namespaces that are being copied here coming
> >from?
> 
> I can explain this. The XSLT specification specifies two relevant things 
> here:
> 
> 1. Sufficient namespace declarations must be output in the output document 
> in order for the namespaces that are _used_ in the output document to still 
> be declared (even if the tags holding the original namespace declarations 
> are not copied).
> 
> 2. Templates CANNOT match on xmlns: attributes at all. If you try, it won't 
> match. I quote:
> 
> "The built-in template rule for namespace nodes is also to do nothing. There 
> is no pattern that can match a namespace node; so, the built-in template 
> rule is the only template rule that is applied for namespace nodes."
> 
> (Namespace nodes == the representation of xmlns: attributes [okay SAX does 
> not have a tree of nodes, but you get the meaning], and should not be 
> confused with the namespace axis, which is what the above code is matching 
> on. See M. Kay, "XSLT Programmers Reference".) This seems like a stupid 
> restriction to me, but it's in the spec, and it's possible to workaround it, 
> so it has to be adhered to. I would guess that it was probably specced this 
> way in order to enforce a separation of concerns, so that only the XSLT 
> processor would have to worry about preserving needed namespace declarations 
> (which could be non-trivial, but could be completely automated - or so the 
> spec writers thought!), not the stylesheet author.
> 
> However, think about this for a second - the XSLT processor is NOT 
> outputting the "real" XML - the Java code it is generating, is doing that! 
> The output document of Xalan, in this case, is a Java source file wrapped in 
> ONE dummy element, which is ignored to make it into a compilable Java source 
> file.
> 
> Because the spec writers did not apparently take into account the fact that 
> XSLT might be used to generate programming language source code which would 
> generate XML (after all - on the face of it - it does seem like a stupid 
> idea, if you put yourself in the shoes of someone who's never used Cocoon or 
> XSP), that is why we have this problem.
> 
> This illustrates a problem with XSLT - it is called "Extensible Stylesheet 
> Transformations", and designed for that purpose - yet clearly people are 
> advocating using it, and depending on using it, for things which have 
> nothing to do with style, because it is in many ways such an eminently 
> suitable tool.
> 
> Anyway. In C1, Ricardo first implemented a hackaround so that if you needed 
> namespace declarations preserved, you used xsp: for them instead of xmlns:. 
> Since this was non-standards-compliant he improved it, in 1.8 and 2.0alpha, 
> to pick up all namespaces used automatically.
> 
> The 1.8 "solution" is really bad because it outputs namespace declarations 
> in lots of elements (perhaps all). The 2.0alpha solution, though different, 
> seems also to emit redundant declarations.
> 
> The best solution seems to be to scrap those methods and instead:
> 
> 1) Record all namespace declarations in a Map.
> 2) Record only the namespaces that will be outputted _explicitly_ 
> (namespaces used by support classes are their responsibility, so we only 
> have to worry about the generated code).
> 3) Look up (2) in the (1) Map to generate the declarations, so that unused 
> declarations are ommitted.
> 4) Output these declarations only in the page root element, since that will 
> apply throughout the whole document.
> 
> None of this can be done in XSLT directly, but it doesn't need to be, we can 
> just do it in Java.
> 
> 
> (Of course in Cocoon 1 think Hashtable instead of Map.)
> 
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at 
> http://profiles.msn.com.
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/