Expand 8.3 filenames during URL normalization

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use Windows XP
2. Extract the Pipeline 2 v1.5 Web UI Desktop version to the desktop (or 
anywhere else under C:\Documents and Settings)
3. Start it
4. Try converting a book using DAISY 2.02 to EPUB3

"DOCUME~1" will be used as the 8.3 filename instead of "Documents and Settings" 
when the Web UI passes the absolute URI to the NCC as a script option. In the 
fileset, the path to the NCC will thus contain "DOCUME~1", which is a valid URI 
and works for loading and storing under Windows. However, the base URI returned 
by calling the base-uri(/*) XPath function will contain the expanded "Documents 
and Settings" directory name, which makes it impossible to use string 
comparison on the absolute file URIs.

Ideally, 8.3 filenames should be expanded during URL normalization.

Original issue reported on code.google.com by josteinaj@gmail.com on 5 Jun 2013 at 9:13

[GoogleCodeExporter]

May not belong to URI normalization, but I agree we should provide a function 
for it. To be used as early as possible in the scripts, e.g. when we create the 
fileset.

Original comment by rdeltour@gmail.com on 11 Jun 2013 at 12:28

[GoogleCodeExporter]

On hrefs passed to px:fileset-create and px:fileset-add-entry.

Original comment by josteinaj@gmail.com on 11 Jun 2013 at 12:30

[GoogleCodeExporter]

File.getCanonicalPath() seems to perform expansion of 8.3 filenames. (tested in 
Win XP - implemented in the Web UI)

http://docs.oracle.com/javase/6/docs/api/java/io/File.html#getCanonicalPath()

Original comment by josteinaj@gmail.com on 26 Jun 2013 at 8:35

[GoogleCodeExporter]

OK, we can create a custom Java function calling File#getCanonicalPath, and 
call it in px:fileset-create / px:fileset-add-entry (ideally, we should test if 
the function is available first, to ensure maximum compatibility with vanilla 
XProc).

Original comment by rdeltour@gmail.com on 2 Jul 2013 at 9:02