Re: [xslt] create Directory bug in libxslt for W32

[Daniel Veillard <veillard redhat com>]

On Wed, Dec 01, 2004 at 07:19:59PM -0600, Aleksey Gurtovoy wrote:
> Daniel Veillard writes:
> > On Tue, Nov 30, 2004 at 03:10:38PM -0600, Aleksey Gurtovoy wrote:
> > > Thomas Fischer writes:
> > > > Hi folks,
> > > > i found a bug in libxslt and Daniel Veillard told me, that's
> > > > a win only bug and he can't help   :o<
> > > > 
> > > > The Bug occurs, when i try to create a directory via command
> > > > line parameter --output (like "xsltproc -o does_not_exist/res ...")
> > > > or via <exslt:document href="does_not_exist/res"
> > > > 
> > > > Anybody knows a workaround or patch for this problem?
> > > 
> > > See the attachments for the latter (against the current CVS).
> > 
> >   I do not understand the first patch nor the associated
> > side effects. On windows the file path separator is '\' why is this
> > wrong and need to be removed.
> 
> I agree that the patch is a little controversial, but only due to the fact 
> that 'xmlParserGetDirectory' is used to extract directory paths from both 
> URI/URLs _and_ file system paths. For the former the running platform is 
> irrelevant; for the latter it's not (obviously). I'm not that familiar with
> the libxslt/libxml2 codebase to be able to say in how many cases when a
> function is passed a 'filename' argument it actually _is_ a native 
> filesystem path (as opposite to a URL), but I assume that at least some 
> of them are. Of course you're in much better position to answer this.
> 
> In any case, my take on the issue is that, ideally, all current calls
> to 'xmlParserGetDirectory' should become calls to either 
> 'xmlParserGetURIDirectory' or 'xmlParserGetFileDirectory' (both currently 
> non-existent), the latter differing from the former in that it would 
> respect the running platform's conventions.
> 
> Does it make sense to you?

  yes, except if xmlParserGetURIDirectory is by all means the same as
xmlParserGetDirectory then I would rather indicate in the doc that it should
be used on URI and not change the name. The API is already huge. I also
don't know exactly where xmlParserGetFileDirectory should be called, 
i.e. where we are sure that the name for the resource is garanteed to
be a file path.

  I'm not fond of the other suggestion to use either '/' or '\', 
in the function, people are using things like
    http://example.org/goo\bar
and 
    file:///foo\bar
and I prefer to not introduce more ambiguity in the way we process
file paths and URIs.

  On a related note someone should look at the new IETF draft for file URIs

    http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-02.txt

and try to see if we can improve the implementation on Windows to support
all the file convention that they list.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/