Excellent. Thank you. I've applied that patch. On 04/01/07, Yang ZHONG <[EMAIL PROTECTED]> wrote:
xmlCanonicPath and comment have been attached as http://issues.apache.org/jira/secure/attachment/12348285/WindowsPath.support On 1/4/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > On 04/01/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > I have a couple of comments. > > > > 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain > what > > the code is doing and why. > > > > 2. Regarding xmlCanonicPath, performance is not an issue. This section > of > > code won't be called often enough to matter, whereas reliability and > > clarity > > (for people reading it in future) are essential. So whether we use > > xmlCanonicPath or not should be based on which one is easier to > understand > > in future. > > > > Caroline, I've looked on the libxml2 website and the description of > > xmlCanonicPath that I found is pretty thin. Do you have a pointer to a > > decent explanation of what it does? > > > > Well, this is open source :-) > > Here's the prolog: > > */** > * xmlCanonicPath: > * @path: the resource locator in a filesystem notation > * > * Constructs a canonic path from the specified path. > * > * Returns a new canonic path, or a duplicate of the path parameter if > the > * construction fails. The caller is responsible for freeing the memory > occupied > * by the returned string. If there is insufficient memory available, or > the > * argument is NULL, the function returns NULL. > */* > > and you can view the source at: > http://cvs.gnome.org/viewcvs/libxml2/uri.c?view=markup > (search for xmlCanonicPath) > > You'll see the the logic is very similar to Yang's, but IMHO it serves the > project better to reuse a function from a supported open-source library > that > the project already depends on than to reinvent it. Personally I wouldn't > see the extra memory allocation as an issue. > > -- > Caroline > > -- Yang ZHONG
