Re: [xslt] libxslt escaping urls when outputting HTML

["Wesley W. Terpstra" <wesley terpstra ca>]

On Fri, Sep 06, 2002 at 05:46:04AM -0400, Daniel Veillard wrote:
> On Fri, Sep 06, 2002 at 03:58:38PM +1000, Andy Hird wrote:
> [...]
> > and with version 1.18 (and version 1.20 I just tested) we get:
> > 
> > <a href="http://foobar.com/hello%2Cworld";>test</a>
> > 
> > 
> > I know that they are, in essence, the same thing but unfortunately we
> > have some software relying on the former output (which we will fix). 
> > 
> > I was curious what prompted the change in libxslt and whether there was
> > a way (within the xslt) of changing that escaping for the whole document
> > (rather than using xsl:text elements with escape exceptions).
> 
>   The reason is simple: standard conformance
>     http://www.w3.org/TR/xslt#section-HTML-Output-Method
> 
>     "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."

Uhm, forgive me if I am mistaken, but isn't "," an ASCII character?
So "should escape _non_-ASCII characters" does not apply?

I read this part of the specification to be refering to utf-8, but
non-asciii characters... 
So, a german umlaut would be utf-8->uri encoded, but a comma should not?

> However considering the complexity of the issue, maybe it's a good thing 
> to not rely on the former output anyway, and there isn't a way to avoid the
> escaping (even the xsl:text trick won't work in that case, the URI serializer
> won't look at this, the escaping disabling wasn't intended for this).

There is supposed to be an parameter to the xsl:output element in XSL 2.0 to
turn this off as well, but I don't think it was in 1.0?

Again, though, I believe this is only supposed to apply to non-ascii utf-8
characters... I personally think the specification needs to make this
section clearer and simpler: this is really important for those of us who
actually deal with full scale utf-8 in uri POST elements or other non-html
specific locations...

Later.

-- 
Wesley W. Terpstra <wesley@terpstra.ca>