[C1 AND C2] Explanation of Redundant Namespace Prefixes

[Robin Green <gr...@hotmail.com>]

"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.