atom feed19 messages in org.w3.xproc-devRE: Fileutils
FromSent OnAttachments
Norman WalshMay 25, 2009 11:58 am 
David A. LeeMay 25, 2009 2:21 pm 
Norman WalshMay 25, 2009 2:26 pm 
Norman WalshMay 25, 2009 3:11 pm 
Dave PawsonMay 25, 2009 10:04 pm 
mozerMay 25, 2009 11:34 pm 
Toma...@emc.comMay 26, 2009 12:19 am 
Norman WalshMay 26, 2009 5:06 am 
Norman WalshMay 26, 2009 5:07 am 
Norman WalshMay 26, 2009 5:09 am 
Dave PawsonMay 26, 2009 6:49 am 
Norman WalshMay 29, 2009 4:27 am 
Toma...@emc.comMay 29, 2009 4:47 am 
James FullerJun 1, 2009 5:07 am 
Leif WarnerJun 1, 2009 9:28 am 
James FullerJun 1, 2009 9:43 am 
Norman WalshJun 1, 2009 9:43 am 
James FullerJun 1, 2009 10:17 am 
Norman WalshJun 1, 2009 11:22 am 
Subject:RE: Fileutils
From:Toma...@emc.com (Toma@emc.com)
Date:May 26, 2009 12:19:53 am
List:org.w3.xproc-dev

Great work!

Q: Should "file" be made absolute wrt to the current base URI, or left unchanged (effectively making it relative to the implementations notion of current working directory)?

I would say the former (make absolute against the current base URI) since it would be more consistent with how the core XProc steps behave. For instance, the p:load and p:store steps, or the p:document construct use the current base URI. (On the other hand, I am well aware of the problems with getting the current working directory in XProc...)

Just one thought: what about making these steps more generic, and make the use an "href" option instead of "file"? That would allow implementations to support also other URI schemes than "file".

For instance, in our implementation we support a whole bunch of URI schemes, and support for additional URI schemes can be easily providedby the user/programmer. I can imagine that one may want to use the fileutils steps to access the classpath, for instance, or even collections/documents in a native XML database, ... In our implementation, all you have to do is to pass a different URI scheme to the XProc steps.

Just thinking.

Regards, Vojtech