XSLT entity problem in attribute

[Bloody Viking]

Namaste, Y'all!

I've got a problem I'm hoping one of you can solve. My stylesheet has
the following bit of code:

<xsl:template match="web|WEB">
<xsl:variable name="url">
<xsl:value-of select='translate(.," &#x9;&#xa;&#xd;", "")'/>
</xsl:variable>
<a><xsl:attribute name="href"><xsl:if
test="not(starts-with($url,'http'))">http://</xsl:if><xsl:value-of
select="$url"/></xsl:attribute>
<xsl:value-of select="$url"/>
</a>
</xsl:template>

Given the following XML:

<othinfo>
<italic>New York Times</italic>, (Available at <WEB
URL="http://www.mat.
jhu.edu/∼sormani/affirm-impact.html">http://www.mat.jhu.ed
u/∼sormani/affirm-impact.html</WEB>)
</othinfo>

the resultant HTML is:
<em>New York Times</em>, (Available at <a
href="http://www.mat.jhu.edu/%E2%88%BC
sormani/affirm-impact.html">http://www.mat.jhu.edu/&sim;sormani/affirm-impact.ht
ml</a>)

As you can see, ∼ is correctly translated to &sim; in the text
part of the resultant <a> element, but is for some reason translated to
%E2%88%BC in the href attribute. If I remove the translate function,
and just have
<xsl:variable name="url"><xsl:value-of select='.'/></xsl:variable>
the result is identical.

- Paul Lieberman

[Peter Flynn]

Bloody Viking wrote:

Namaste, Y'all!

I've got a problem I'm hoping one of you can solve. My stylesheet has
the following bit of code:

<xsl:template match="web|WEB">
<xsl:variable name="url">
<xsl:value-of select='translate(.," &#x9;&#xa;&#xd;", "")'/>
</xsl:variable>
OK, so you're squashing out all spaces, TABs, CRs, and LFs.
<a><xsl:attribute name="href"><xsl:if
test="not(starts-with($url,'http'))">http://</xsl:if><xsl:value-of
select="$url"/></xsl:attribute>
<xsl:value-of select="$url"/>
</a>
</xsl:template>
OK, except I'm not clear why two innocuous slashes have been given
as numeric references. Makes no difference to the program, just
makes it harder to read.
Given the following XML:
Is there a reason why some normal characters have been given as
numeric references here as well?
<othinfo>
<italic>New York Times</italic>, (Available at <WEB
URL="http://www.mat.
jhu.edu/∼sormani/affirm-impact.html">http://www.mat.jhu.ed
u/∼sormani/affirm-impact.html</WEB>)
</othinfo>
What is that 8764 doing there? It should be a tilde (&#x7E;).
the resultant HTML is:
<em>New York Times</em>, (Available at <a
href="http://www.mat.jhu.edu/%E2%88%BC
sormani/affirm-impact.html">http://www.mat.jhu.edu/&sim;sormani/affirm-impact.ht
ml</a>)

As you can see, ∼ is correctly translated to &sim; in the text
Yes, but a &sim; is not what you want. You want a tilde there. A sim
is a math graphic character and has no place in a URI.
part of the resultant <a> element, but is for some reason translated to
%E2%88%BC in the href attribute.
That's because the 8764 shouldn't be there in the first place.

At a guess:

Your converter has re-encoded it as three bytes representing the
Unicode for a sim character because you can't use Unicode characters
in URIs (yet, wait until the Chinese proposal goes through :-)

It didn't convert it in the text because Unicode might be allowed
there, eventually (depending on the actual output encoding).
If I remove the translate function,
and just have
<xsl:variable name="url"><xsl:value-of select='.'/></xsl:variable>
the result is identical.

No, get rid of the 8764 from the input: it's just bad data. Or
translate it to a tilde character, which is correct. And maybe
turn those 47s back into slashes to make it easier to check.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

[Richard Tobin]

In article <11*********************@u72g2000cwu.googlegroups. com>,
Bloody Viking <pa************@alum.mit.edu> wrote:

As you can see, ∼ is correctly translated to &sim; in the text
part of the resultant <a> element, but is for some reason translated to
%E2%88%BC in the href attribute.

This is what the HTML output method is supposed to do. The XSLT 1.0
spec says:

The html output method should escape non-ASCII characters in URI
attribute values using the method recommended in Section B.2.1 of
the HTML 4.0 Recommendation.

This should not be a problem for you: it represents the same
character. URIs are not allowed to contain non-ASCII characters, and
a web browser would do this translation itself if it were not already
done in the HTML.

-- Richard

[Richard Tobin]

In article <48************@individual.net>,
Peter Flynn <re*********@m.from.email.address> wrote:

Your converter has re-encoded it as three bytes representing the
Unicode for a sim character because you can't use Unicode characters
in URIs (yet, wait until the Chinese proposal goes through :-)

No need to wait for a Chinese proposal, we already have IRIs:

http://www.ietf.org/rfc/rfc3987.txt

-- Richard