Re: [xslt] Possible parsing bug?

["Martin (gzlist)" <gzlist googlemail com>]

Note, has nothing to do with parsing, and isn't really a bug.

On 30/10/2008, Dave Connet <connet entelos com> wrote:
>
> Are there any work arounds to this? (I'm not the xsl programmer - I wrote
> the C++ code to do the transformations)

There's an easy answer here: use a less bogus stylesheet so you are
outputting a valid URL (or close enough). For instance, something
like:

- <img>
-  <xsl:attribute name="width">415</xsl:attribute>
-  <xsl:attribute name="height">10</xsl:attribute>
-  <xsl:attribute name="src"><xsl:value-of
select="/Root/@PathName"/>images/myImage.gif</xsl:attribute>
- </img>
+ <img width="415" height="10"
+  src="file:///{translate(/Root/@PathName,'\','/')}images/myImage.gif"/>


It's a harder question as to whether the libxslt behaviour here is
correct. Chasing back through the specifications:
<http://www.w3.org/TR/xslt#section-HTML-Output-Method>
Says nothing about URIs specifically, but notes "..the result should
be output as HTML conforming to the HTML 4.0 Recommendation".
<http://www.w3.org/TR/REC-html40/types.html#type-uri>
Isn't terribly useful in that it defers to the relevant RFCs. The DTD
type is just CDATA, but the spec is clear about having requirements
beyond those that can be tested by a schema. RFC 1738, RFC 2396, RFC
3986 all say what we already know, backslash and space may not appear
unescaped in a URL.
<http://www.ietf.org/rfc/rfc1738.txt>
Explicitly blacklists space and backslash as "unsafe".
<http://www.ietf.org/rfc/rfc3986.txt>
Specifies "reserved" and "unreserved" characters that may appear raw,
everything else (including spaces and backslashes) must be
percent-encoded.

So, you can certainly derive the current logic, though it's not
explicit anywhere. Even if libxslt were changed to allow invalid URIs
in html output, other processors such as transformiix in mozilla seem
to behave similarly, so just fixing your xslt looks the obvious
choice.

Martin