tags:

views:

52

answers:

5

I have the following XSLT

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"    xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
    <xsl:output method="html" omit-xml-declaration="yes" />
    <xsl:strip-space elements="*"/>
    <xsl:template match="@* | node()">
        <xsl:copy>

          <html>
            <body>
            <xsl:for-each select="AdvReqIMailMsg">

              <a><xsl:attribute name="href">
                  http://&lt;xsl:value-of select="BackSideUrl"/>/customerlogin.asp?P=<xsl:value-of select="DynaCalPath"/></xsl:attribute >
                Login to View History of This Request
              </a>
              <br/>
            </xsl:for-each>
            </body>
          </html>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

The result has the following:

<a href="&#xA;                  http://dotnet.dynacal.com/customerlogin.asp?P=DEMO8"&gt;
                Login to View History of This Request
              </a>

Why are the &#xA; and all the spaces there? I am new to XSLT and my google searches haven't turned anything up that I understood. Thanks, Shawn

+2  A: 

The &#A; is an encoded newline character.

It and the spaces are preserved from the newline and spaces in your XSLT.

SLaks
+1  A: 

I'm not really familiar with XSLT myself either, but as a guess from general programming experience, try changing

<xsl:attribute name="href">
                  http://&lt;xsl:value-of select="BackSideUrl"/>/customerlogin.asp?P=<xsl:value-of select="DynaCalPath"/></xsl:attribute >

to

<xsl:attribute name="href">http://&lt;xsl:value-of select="BackSideUrl"/>/customerlogin.asp?P=<xsl:value-of select="DynaCalPath"/></xsl:attribute >
Bart van Heukelom
+1  A: 

The number of spaces in the output match exactly the number of spaces before http... in you xslt. Remove those and the newline, and you should be fine.

bitmask
+2  A: 

The whitespace is preserved when you mix text and element nodes. So one solution is to avoid the whitespace to begin with (as shown by Bart), or to do the following, which may be more readable since it gets formatted well:

<xsl:attribute name="href">
    <xsl:text>http://&lt;/xsl:text&gt;
    <xsl:value-of select="BackSideUrl"/>
    <xsl:text>/customerlogin.asp?P=</xsl:text>
    <xsl:value-of select="DynaCalPath"/>
</xsl:attribute >
Lucero
"The whitespace is preserved when you mix text and element nodes." I think I know what you mean but I don't think this statement is true as written. Rather, whitespace is preserved when (among other times) it is in the same text node with non-whitespace text, i.e. the whitespace and non-whitespace are together without intervening start or end tags. And the latter often occurs when you mix text and elements as siblings, but not necessarily, and not only then.
LarsH
@LarsH, you're correct, it is a broad simplification. The problem is that the formatter of Visual Studio seems to ignore this in the case described and happily inserts line breaks where they are in fact significant. Therefore, if you follow the rule that you don't mix text and elements as content (that is, make all elements contain text only or elements with optional whitespace, but not both), the formatter will not break your documents. That's the reason why I wrote this simplification - it should help to avoid getting broken documents.
Lucero
+4  A: 

Just use:

<a href="http://{BackSideUrl}/customerlogin.asp?P={DynaCalPath}"&gt;
           Login to View History of This Request
</a>

This (use of AVT -- Attribute-Value-Templates) is both shorter and more readable.

The reason for the reported behavior, as explained in almost all answers, is that the value of the attribute href is constructed (partly) from text-node that contains the NL character.

Such issues are result from a purely human, psychological phenomenon: we clearly see the NL whenever it is surrounded by non-white-space, however we are NL-blind whenever the NL is at the start or at the end of a block of text. It would be a useful feature of any XSLT/XML IDE to show on request groups of special "invisible" characters, such as NL and CR.

Dimitre Novatchev
You're right, that's probably the nicest solution here. But you did not explain *why* this happens, and this was explicitly part of the question! ;-)
Lucero
@Lucero: All other people explained why this happenned -- I see no need to repeat their explanations. :)
Dimitre Novatchev
@Lucero: Added a short explanation to the answer.
Dimitre Novatchev
+1 For a good answer and AVT recommendation.
Alejandro
@Lucero: In fact, I don't think anyone have properly give an explanation. From http://www.w3.org/TR/xslt#strip : `After the tree for a source document or stylesheet document has been constructed, but before it is otherwise processed by XSLT, some text nodes are stripped. A text node is never stripped unless it contains only whitespace characters.` Rules for XSLT 2.0 are a bit different.
Alejandro
@Alejandro: Everyone knows this -- no need to tell them. If non-white-space-nodes could be stripped, then nothing would work in XSLT as it does -- including literal result elements and text.
Dimitre Novatchev
@Dimitre: You are right about that nothing would work otherwise. But this really makes anyone think in all the implications behind stylesheets been XML trees.
Alejandro
@Alejandro: I was going to say, nobody has explained why whitespace was not stripped here. But now you did. :-) @Dimitre: +1 for compact and readable Attribute Value Template. But I disagree that "everyone knows this" regarding whitespace stripping. I've been using XSLT professionally for years, and the details of the whitespace stripping rules are something I often forget, e.g. how does it work in stylesheets as distinct from source documents. I know now only because I just looked it up.
LarsH
@LarsH: Thanks. By "everyone knows this" I mean that everyone *unconsciously* knows this -- otherwise XSLT wouldn't "work" as it does.
Dimitre Novatchev
@LarsH, @Alejandro: Just added *psychological* explanation.
Dimitre Novatchev
@Dimitre: I guess I understand what you mean by "unconsciously knows this", and usually things work the way you need them to. But very often there are cases where newbies (and I) find ourselves facing a situation where it *doesn't* work like we want (like here), and then we need to *consciously* know (some of) the whitespace rules, in order to be able to fix the problem.
LarsH
@LarsH: I think that the psychological explanation shows why the reasons for such confusion are at the subconscious level -- no matter how one reads, the subconscious is always stonger and always takes precedence. Hmm... don't think of me as a savage... :)
Dimitre Novatchev