canonical windows file paths

[Shane Clauson]

Hi Andrew,
I've been a bit snowed-under and your post just now reminded me that I
need to get some mods back to the user group.

I have modified FoX for our use here in in a number of ways which /may/
or /may not/
be in keeping with the spirit of the original implementation.
A complicating issue here is I've not built the relevant fox test suites
to verify
if these changes will cause regression for other users....

An example of very recent change is enabling FoX to understand URIs that
contain
canonical windows paths like "file:///c:/myActivty.xml"
q.v. <http://en.wikipedia.org/wiki/File_URI_scheme>

I've attached the diffs for how I've addressed this particular issue here.
Have are other fox/windows users encountered this problem ?.

Another example is that we've extended the feedback given from the
sax tokeniser & parser when errors are encountered in the input.
The changes for this are somewhat more far reaching, are people interested
in these sorts of changes ?

Cheers,
Shane

[Andrew Walker]

Thanks for this Shane,

I've taken a look at your windows filename patch and it doesn't seem to
break any of the I've got tests to hand for apart from a single check in
the utils tests aimed at the windows case.

The test looks to see what comes out of
parseURI("file:///C:/a%20ctivity.xml"). As I understand it the path should
be 'C:/a ctivity.xml' but the URI should be expressed as
'file:///C:/a%20ctivity.xml'? Currently FoX includes a root slash in the
path (wrong?) and the three slashes in the URI (right?). Your patch gives
no root slash (right?) but only two slashes in the URI (wrong?). If this
is correct I can see the way to do this quite easily. I wonder if it's
worth making this a compile time option?

I would be interested in seeing your sax error reporting changes. There
could be nasty interaction between the sax and dom modules that would need
thinking about.

Cheers,

Andrew

--

[Shane Clauson]

Hi Andrew,
Thanks for looking at this, replies inline.

On 4/05/2012 5:21 AM, Andrew Walker wrote:

Thanks for this Shane,

I've taken a look at your windows filename patch and it doesn't seem to
break any of the I've got tests to hand for apart from a single check in
the utils tests aimed at the windows case.

The test looks to see what comes out of
parseURI("file:///C:/a%20ctivity.xml"). As I understand it the path should
be 'C:/a ctivity.xml' but the URI should be expressed as
'file:///C:/a%20ctivity.xml'? Currently FoX includes a root slash in the
path (wrong?) and the three slashes in the URI (right?). Your patch gives
no root slash (right?) but only two slashes in the URI (wrong?). If this
is correct I can see the way to do this quite easily. I wonder if it's
worth making this a compile time option?

At the end of the day, its the root slash at the head of a path that uses a drive specifier
at file open is what's causing grief for windows.
When 3rd party java applications (eg jaxe, xerlin) are
reading the xml files on windows, they are expecting to encounter a doctype line like so

a) <!DOCTYPE Activity SYSTEM "file:///c:/some%20Path/MyActivity.dtd" >
or so 
b) <!DOCTYPE Activity SYSTEM "c:/some%20Path/MyActivity.dtd" >

Currently to accomplish this in fox on windows we need to always specify the file scheme,
and supply one less slash (which then breaks on the other systems),  as

<!DOCTYPE Activity SYSTEM "file://c:/some%20Path/MyActivity.dtd" >

For instances where relative paths (like "../../myArchive/MyActivity.dtd") or local files are sufficient,
then life is the same and there is no problem.
My fix is intended to address the need in the specific cases of both a) & b) above.

This is all separate from the nasty windows habit of permitting
spaces within a file name. For this latter issue when specifying files to fox either as the
file to open or when embedded in the document as say an external dtd reference
in a <!doctype> element, my application code has been explicitly percent-encoding
any spaces (or '#@?' characters) before fox sees them,
so they will not be potentially interpreted as part of the uri syntax.
I'm unclear as to how/if FoX should handle spaces and special characters differently
on windows, as this explicit encoding step has been working well for my application code
here to date ...

I've been toying with the idea of a windows compile-time flag for a variety of issues,
so yes, perhaps it will be useful to introduce one.  Referring to
<http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/bldaps_for/common/bldaps_use_presym.htm>
Intel fortran always predefines the symbol "_WIN32"
(this is true even on 64 bit systems, which confusingly also always have the "_WIN32" symbol defined,
  but are differentiated by the addition of another symbol, "_WIN64").
So "_WIN32" would be a good candidate.

I would be interested in seeing your sax error reporting changes. There
could be nasty interaction between the sax and dom modules that would need
thinking about.

Perhaps you've not had a chance to check git yet ?
I've merged Jacek's sax mods with mine and pushed the faster + error reporting result
to my fox fork for you to look at.

As there is a bit of windows/intel fortran use on the group,
I'll also push a FoX.vfproj to git for you to consider,
as some may find this a useful starting point when working with the visual studio toolset.
 
Take Care,
Shane. 

[Andrew Walker]

Hi Shane,

On Fri, May 4, 2012 1:01 am, Shane Clauson wrote:

>>
>> I would be interested in seeing your sax error reporting changes. There
>> could be nasty interaction between the sax and dom modules that would
>> need
>> thinking about.
>
> Perhaps you've not had a chance to check git yet ?
> I've merged Jacek's sax mods with mine and pushed the faster + error
> reporting result
> to my fox fork for you to look at.
>
> As there is a bit of windows/intel fortran use on the group,
> I'll also push a FoX.vfproj to git for you to consider,
> as some may find this a useful starting point when working with the
> visual studio toolset.

Many thanks - I've merged these.

(I still need to find time to think about the best way to handle the
details of the URI thing, and especially the tests, but this is merged
too.)

Cheers,

Andrew