cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <>
Subject Re: [C1 AND C2] Explanation of Redundant Namespace Prefixes
Date Sun, 22 Oct 2000 03:45:51 GMT

Davanum, I'm having a little trouble grocking the real issues with Xalan in
this note, and need a shorter summary of what you feel is the issue in

> > 2. Templates CANNOT match on xmlns: attributes at all. If you try, it
>> match. I quote:

I don't think I'm drawing the connection from this to a potential problem
with namespaces.

> Can we have a switch
> ("setFeature/getFeature") to be able to preserve namespaces in Xalan2J?

I'm not sure what this means.  Preserve the actual prefixes?  Xalan does
preserve namespaces from the input to the output, as much is it can, unless
the namespace is specified in exclude result prefixes.

Obviously I'm not fully following this.  Late at night at ApacheCon, what
can I say?


                    Srinivas             To:               
                    <dims@yahoo.c        cc:, (bcc: Scott
                    om>                  Subject:     Re: [C1 AND C2] Explanation of Redundant
Namespace Prefixes  
                    09:06 PM                                                             
                    respond to                                                           

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?


--- Robin Green <> wrote:
> "Per Kreipke" <> wrote:
> >Ok, so the bug isn't in the esql taglib, the extra namespace attributes
> >coming from the xsp processor itself, in xsp-java.xsl. The following
> >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
> >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
> in order for the namespaces that are _used_ in the output document to
> 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
> match. I quote:
> "The built-in template rule for namespace nodes is also to do nothing.
> 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
> 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
> 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
> so it has to be adhered to. I would guess that it was probably specced
> way in order to enforce a separation of concerns, so that only the XSLT
> processor would have to worry about preserving needed namespace
> (which could be non-trivial, but could be completely automated - or so
> 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
> The output document of Xalan, in this case, is a Java source file wrapped
> ONE dummy element, which is ignored to make it into a compilable Java
> file.
> Because the spec writers did not apparently take into account the fact
> XSLT might be used to generate programming language source code which
> 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
> XSP), that is why we have this problem.
> This illustrates a problem with XSLT - it is called "Extensible
> 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
> namespace declarations preserved, you used xsp: for them instead of
> Since this was non-standards-compliant he improved it, in 1.8 and
> to pick up all namespaces used automatically.
> The 1.8 "solution" is really bad because it outputs namespace
> in lots of elements (perhaps all). The 2.0alpha solution, though
> 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
> declarations are ommitted.
> 4) Output these declarations only in the page root element, since that
> apply throughout the whole document.
> None of this can be done in XSLT directly, but it doesn't need to be, we
> 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
> Share information about yourself, create your own public profile at

Davanum Srinivas, JNI-FAQ Manager

Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.

View raw message