cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
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
Xalan.

> > 2. Templates CANNOT match on xmlns: attributes at all. If you try, it
won't
>> 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?

-scott




                                                                                         
                         
                    Davanum                                                              
                         
                    Srinivas             To:     cocoon-dev@xml.apache.org               
                         
                    <dims@yahoo.c        cc:     xalan-dev@xml.apache.org, (bcc: Scott
Boag/CAM/Lotus)             
                    om>                  Subject:     Re: [C1 AND C2] Explanation of Redundant
Namespace Prefixes  
                                                                                         
                         
                    10/20/2000                                                           
                         
                    09:06 PM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         




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 <greenrd@hotmail.com> wrote:
> "Per Kreipke" <per@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/





Mime
View raw message