Very Computer

I want my XSL transform to generate the following literal HTML:

<input type="submit" name="foo" value="abc &eacute; def"></input>

The problem is that no matter how I try to code this in the stylesheet,
Xalan's HTML output method insists on expanding the entity reference inside
the "value" attribute.  

The stylesheet's header looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
  <xsl:output method="html" encoding="UTF-8"/>

and the source which I'm attempting to make work looks like this:
<input type="submit" name="foo">
  <xsl:attribute name="value">abc &#224; def</xsl:attribute>
</input>

I've tried various combinations of CDATA sections and of an xsl:text
elements...nothing has worked so far.  What am I doing wrong?

Tnx,
Eric

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ETA Associates, Inc.
http://www.ultracode.com/

Quote:> I'm trying to do what I think would be a relatively straightforward thing,
> but am having zero luck.  I hope some XSL whiz can help me out.

> I want my XSL transform to generate the following literal HTML:

> <input type="submit" name="foo" value="abc &eacute; def"></input>

> The problem is that no matter how I try to code this in the stylesheet,
> Xalan's HTML output method insists on expanding the entity reference
inside
> the "value" attribute.

> The stylesheet's header looks like this:

> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
>   <xsl:output method="html" encoding="UTF-8"/>

> and the source which I'm attempting to make work looks like this:
> <input type="submit" name="foo">
>   <xsl:attribute name="value">abc &#224; def</xsl:attribute>
> </input>

If your encoding is right (utf-8), then what you are getting is valid XML.
If you view it with a utf-8 capable editor, it will 'look' right too.

Its XML you're dealing with, not ASCII.

HTH DaveP

If what you say is true, then why is Xalan translating &#244; into &eacute;
everywhere *except* inside of attribute values?  It's being inconsistent -
doing the "right" (IMO) thing for element values, but not for attribute
values.

I know enough XSL to be dangerous - not a guru.  As such, it would seem to
me that when using the HTML output method the result would be pretty
ordinary, conforming HTML.  &eacute; is ordinary HTML.

This is not an academic exercise - I'm trying to find a workaround for what
appears to be a Netscape/Mozilla bug.  Neither browser seems to like
UTF-8-encoded chars in INPUT button titles.  Both display a "?" in place of
the offending character.  They *are* happy when the character is encoded as
a normal HTML entity (i.e. &eacute).  

This HTML stream is being generated by a servlet and I'm being careful to
set the content-type to text/html; charset=UTF-8.  The browsers seem to
understand that the document is UTF-8 encoded so that doesn't appear to be
the problem.

Tnx,
Eric

"Eric Anderson"

Quote:> If what you say is true, then why is Xalan translating &#244; into
&eacute;
> everywhere *except* inside of attribute values?  It's being inconsistent -
> doing the "right" (IMO) thing for element values, but not for attribute
> values.

> I know enough XSL to be dangerous - not a guru.  As such, it would seem to
> me that when using the HTML output method the result would be pretty
> ordinary, conforming HTML.  &eacute; is ordinary HTML.

DaveP

Quote:> Dave,

> If what you say is true, then why is Xalan translating &#244; into
&eacute;
> everywhere *except* inside of attribute values?  It's being inconsistent -
> doing the "right" (IMO) thing for element values, but not for attribute
> values.

The string type may take any literal string as a value;  3.3.1

Then the whitespace and ents are sorted, 3.3.3

Before the value of an attribute is passed to the application or checked for
validity, the XML processor must normalize it as follows:

a character reference is processed by appending the referenced character to
the attribute value
an entity reference is processed by recursively processing the replacement
text of the entity
a whitespace character (#x20, #xD, #xA, #x9) is processed by appending #x20
to the normalized value, except that only a single #x20 is appended for a
"#xD#xA" sequence that is part of an external parsed entity or the literal
entity value of an internal parsed entity
other characters are processed by appending them to the normalized value
If the declared value is not CDATA, then the XML processor must further
process the normalized attribute value by discarding any leading and
trailing space (#x20) characters, and by replacing sequences of space (#x20)
characters by a single space (#x20) character.

You sure you're not falling foul here anywhere?

DaveP