(As posted to http://webkit.opendarwin.org/blog/?p=32#comments) The document() function in XSLT doesn't handle relative pathnames. Enclosed is a simple test case which tries several different methods to extract some information from a document, but only the full path (with file:// prefix) works. I'm not sure of the strict legality of the test case, but other XSLT engines (eg xsltproc) handle this situation well.
Created attachment 4578 [details] Zipfile containting sample stylesheet and test document
Forgot to mention this is WebKit 416.12, Safari 2.0.2
Created attachment 5427 [details] proposed fix
Comment on attachment 5427 [details] proposed fix I talked with ap on irc. I'm dubious about the ascii() to utf8() change, as it was my impression that all libxml2 apis which specify const char * take a latin1 string, those which specify xmlChar * take a utf8 string. But I could be wrong. I asked him to provide a test case for this change. Darin also pointed out a problem with ap's URL manipulation on irc, so r- this one.
Comment on attachment 5427 [details] proposed fix The relative URL resolution should use the KURL constructor that takes a base URL and a relative string. There should not be the code to check isValid() and the code that calls setPath. Otherwise looks good.
I think the UTF-8 change is correct, but I'd like to see a test case that fails with ascii() and succeeds with utf8() to prove it.
Created attachment 5430 [details] non-ASCII paths test A test with non-ASCII paths. Shows that utf8() is a correct choice for the base URL, but resources that have non-ASCII names still cannot be loaded. Since xsltproc has the same problem (and Firefox doesn't), this sounds like a bug in libxslt.
Oops, I spoke too fast - this test works with either utf8() or ascii() - because xmlDocPtrForString() gets percent-encoded ASCII URLs from its caller. Now, there may be issues related to which encoding was used to form the URL, but since libxslt seems to have problems here, there's probably not much sense in investigating this right now (but I'll file a separate bug to track this).
Created attachment 5432 [details] updated patch
Comment on attachment 5432 [details] updated patch (const char *)xmlNodeGetBase(((xsltTransformContextPtr)ctxt)->document->doc, ((xsltTransformContextPtr)ctxt)->node) Could be made slightly clearer using a local variable. Otherwise it looks totally fine. I don't have quite enough xlst-fu to understand your test case, but I trust you.
Verified against 06-01-2006 nightly build. Test case works nicely, thanks.