Re: [xsl] [Fwd: Unwanted xmlns attributes in ouput html tags]

Subject: Re: [xsl] [Fwd: Unwanted xmlns attributes in ouput html tags]
From: Dinesh Gurram <Dinesh.Gurram@xxxxxxx>
Date: Mon, 29 Sep 2003 10:50:31 +1000
Hi Jeni,

Thanks heaps for your help with this. Your suggestions are fantastic and give me some extra options. However, we have tried the exclude-result-prefixes option and that didn't make any difference.

On the bright side, I have kinda figured out another way to get it to work as well in the mean time. Well, actually I didn't figure it out, I got the idea from one of your previous posts. I am used an internal DTD subset to include the include files like so:

<?xml version="1.0"?>
<!DOCTYPE stylesheet [ <!ENTITY inc2 SYSTEM "inc2.ixsl"> ]>
<ixsl:stylesheet version="1.0"
     xmlns:ixsl="http://www.w3.org/1999/XSL/Transform";
     xmlns:xsl="http://www.w3.org/1999/XSL/TransformAlias";>

  <ixsl:namespace-alias stylesheet-prefix="xsl" result-prefix="ixsl" />
  <ixsl:output method="xml" encoding="utf-8" />

  <!-- ixsl:include href="inc.ixsl" /-->
  &inc2;
  ...
</ixsl:stylesheet>

Can anyone see any problems with this approach?

It seems to work fine for really simple examples but when I used it in our real ixsls it does create some trouble. From what I can gather, it essentially reads in the "inc2.ixsl" and kinda "copies" it into the DTD. This is why the corresponding entity reference is equivalent to the whole file getting "pasted" as is into the stylesheet.

Anyways, getting the the problem, I had some "%" signs in my include file, like for eg. <td width="100%">. The parser confuses this "%" sign for a parameter entity reference and complains. I was able to get around this by escaping all "%" signs with "&#37;".

But the question is, are there other potential problems like this that I am likely to experience because of the DTD method?

Cheers

Dinesh



Jeni Tennison wrote:
Hi Dinesh,


I am hoping someone may have some ideas to help resolve a problem
that I am currently experiencing. It seems rather unique and
specific. I am getting unwanted xmlns attributes appearing in output
html tags in a two-stage transform process and it appears to be due
to the use of includes in the first pass. It also seems to be an
xsl-processor-specific problem.


I'm afraid that it looks as though this problem is down to a bug in
the XSLT processor that you're using. The best course of action would
be to upgrade to a processor that doesn't exhibit the bug, for example
Xalan 2.5.1, but I understand that you can't do that...

To work around the bug, you could try adding
exclude-result-prefixes="xsl" to the <xsl:stylesheet> element in
inc.ixsl to see if that has any effect.

Or you could try generating the elements using <xsl:element> rather
than literal result elements; i.e. use:

<ixsl:template name="my_step_one_template">
  <ixsl:element name="tr">
    <ixsl:element name="td">
      <ixsl:attribute name="bgcolor">#666699</xsl:attribute>
      <ixsl:element name="b">
        Some text output by step one
      </ixsl:element>
    </ixsl:element>
  </ixsl:element>
</ixsl:template>

Or you could try generating <xsl:element> instructions in
intermediate.xsl:

<ixsl:template name="my_step_one_template">
  <xsl:element name="tr">
    <xsl:element name="td">
      <xsl:attribute name="bgcolor">#666699</xsl:attribute>
      <xsl:element name="b">
        Some text output by step one
      </xsl:element>
    </xsl:element>
  </xsl:element>
</ixsl:template>

Getting to the final transform (intermediate.xsl + test_data.xml =>
final.html), it produces:

***** final.html ***********
<html>
<tr xmlns:xsl="http://www.w3.org/1999/XSL/TransformAlias";>
<td bgcolor="#666699"><b>
           Some text output by step one
         </b></td>
</tr>
<tr></tr><p></p></html>
***** end file *************

Notice that "my_step_two_template" didn't get called, or at least
there is no output from that template in "final.html". My
interpretation is that because of the pesky "xmlns" attribute
appearing on the <tr> (with the ".../TransformAlias" URI), the
processor reads the "xsl:call-template" as being in the
"TransformAlias" namespace, hence does not process it, and hence the
xsl template is not called.


The my_step_two_template *is* being called here -- otherwise you
wouldn't get the <p> element after the second <tr> element. You might,
though, get problems if you have XSLT instructions within the <tr>
element -- it depends on what the buggy processor outputs when you
generate XSLT instructions within the <tr> element as generated by
my_step_one_template in inc.ixsl.

By the way, why are you using disable-output-escaping in:


       <xsl:template name="my_step_two_template">
         <xsl:param name="text" />
         <xsl:text disable-output-escaping="yes">&lt;p&gt;</xsl:text>
           <xsl:value-of select="$text" />
         <xsl:text disable-output-escaping="yes">&lt;/p&gt;</xsl:text>
       </xsl:template>


When you would get exactly the same output from a literal result
element:

<xsl:template name="my_step_two_template">
  <xsl:param name="text" />
  <p>
    <xsl:value-of select="$text" />
  </p>
</xsl:template>

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



-- ________________________________________________________________

Dinesh Gurram
Demand Creation Systems IT (DCS IT)
SUN Microsystems Australia Pty Ltd
828 Pacific Highway, Gordon, Sydney, NSW 2072 Australia
Phone (internal): x57081
Phone (external): +61 2 9844 5081
E-mail: dinesh.gurram@xxxxxxx
________________________________________________________________


NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread