Gobo Eiffel Project

Colin Paul Adams wrote:
> I'm getting the following problem:
> 
> -------------------------------------------------------------------------------
> Class / Object      Routine                Nature of exception           Effect
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       search_position @4     slots_position_set:
> <00000000B7747528>  (From DS_SPARSE_CONTAINER)
>                                            Postcondition violated.       Fail
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       search_position @31
> <00000000B7747528>  (From DS_SPARSE_CONTAINER)
>                                            Routine failure.              Fail
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       has @1
> <00000000B7747528>  (From DS_SPARSE_TABLE) Routine failure.              Fail
> -------------------------------------------------------------------------------
> 
> Since has doesn't have any pre-conditions, this seems to be a bug.
> 
> I have created the hash table with make_map. The keys are objects of
> type XM_XPATH_DOCUMENT. 

I looked at the code of hash table and I cannot see any obvious problem,
so I would need to be able to reproduce the bug. Do you have a small
example reproducing the bug?

Also, are you sure that the hash_code of your keys does not change
between the time you insert objects in the hash table and the time
you call `has'?

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> I looked at the code of hash table and I cannot see any
    Eric> obvious problem, so I would need to be able to reproduce the
    Eric> bug. Do you have a small example reproducing the bug?

I have a test case that I'm working on. I could check the code in.

    Eric> Also, are you sure that the hash_code of your keys does not
    Eric> change between the time you insert objects in the hash table
    Eric> and the time you call `has'?

I've checked trough this - the answer is Yes.
-- 
Colin Paul Adams
Preston Lancashire

>>>>> "Colin" == Colin Paul Adams <colin@...> writes:

>>>>> "Eric" == Eric Bezault <ericb@...> writes:
    Eric> I looked at the code of hash table and I cannot see any
    Eric> obvious problem, so I would need to be able to reproduce the
    Eric> bug. Do you have a small example reproducing the bug?

    Colin> I have a test case that I'm working on. I could check the
    Colin> code in.

OK. It's all checked in now.

You can reproduce the failure by changing to $GOBO/test/xml/xslt
and running geant clobber; geant test_debug

I'm afraid this is by no means a small test, but it's all I have.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
> OK. It's all checked in now.
> 
> You can reproduce the failure by changing to $GOBO/test/xml/xslt
> and running geant clobber; geant test_debug

I got the following exception trace, apparently unrelated with
your initial problem:

xslt: system execution failed.
Following is the set of recorded exceptions:

-------------------------------------------------------------------------------
Class / Object      Routine                Nature of exception 
  Effect
-------------------------------------------------------------------------------
UT_URI              make @7                reference_valid:
<00000000016B0BD8>                         Precondition violated. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_CONFIGURATION
                     new_file_resolver_current_directory @2
<00000000016B0688>  (From XM_RESOLVER_FACTORY)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_CONFIGURATION
                     make_with_defaults @2
<00000000016B0688>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XXM_XSLT_TEST_STYLESHEET_BUILDER
                     test_simple @4
<00000000016B05A0>  (From XM_XSLT_TEST_STYLESHEET_BUILDER)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XXM_XSLT_TEST_STYLESHEET_BUILDER
                     execute_i_th @2
<00000000016B05A0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XXM_XSLT_TEST_STYLESHEET_BUILDER
                     execute_without_rescue @3
<00000000016B05A0>  (From TS_TEST_CASE)    Routine failure. 
  Fail
-------------------------------------------------------------------------------
XXM_XSLT_TEST_STYLESHEET_BUILDER
                     execute @5
<00000000016B05A0>  (From TS_TEST_CASE)    Routine failure. 
  Fail
-------------------------------------------------------------------------------
TS_TEST_SUITE       execute @5
<00000000016B0520>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XSLT                execute @12
<00000000016B0048>  (From TS_TESTER)       Routine failure. 
  Fail
-------------------------------------------------------------------------------
XSLT                make @11
<00000000016B0048>  (From TS_TESTER)       Routine failure. 
  Fail
-------------------------------------------------------------------------------
XSLT                root's creation
<00000000016B0048>                         Routine failure. 
  Exit
-------------------------------------------------------------------------------


-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> Colin Paul Adams wrote:
    >> OK. It's all checked in now.  You can reproduce the failure by
    >> changing to $GOBO/test/xml/xslt and running geant clobber;
    >> geant test_debug

    Eric> I got the following exception trace, apparently unrelated
    Eric> with your initial problem:

It would certainly appear unrelated.

    Eric> xslt: system execution failed.  Following is the set of
    Eric> recorded exceptions:

    Eric> -------------------------------------------------------------------------------
    Eric> Class / Object Routine Nature of exception Effect
    Eric> -------------------------------------------------------------------------------
    Eric> UT_URI make @7 reference_valid: <00000000016B0BD8>
    Eric> Precondition violated. Fail

This looks most peculiar. 

Can I ask what are the modification dates against ut_uri.e and
ut_url_encoding.e on your system?
On mine, they are 26th June and 4th August respectively.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
> Can I ask what are the modification dates against ut_uri.e and
> ut_url_encoding.e on your system?
> On mine, they are 26th June and 4th August respectively.

Me too. They are both revision 1.6.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> I got the following exception trace, apparently unrelated
    Eric> with your initial problem:

    Eric> xslt: system execution failed.  Following is the set of
    Eric> recorded exceptions:

    Eric> -------------------------------------------------------------------------------
    Eric> Class / Object Routine Nature of exception Effect
    Eric> -------------------------------------------------------------------------------
    Eric> UT_URI make @7 reference_valid: <00000000016B0BD8>
    Eric> Precondition violated. Fail
    Eric> -------------------------------------------------------------------------------
    Eric> XM_XSLT_CONFIGURATION new_file_resolver_current_directory @2
    Eric> <00000000016B0688> (From XM_RESOLVER_FACTORY) Routine
    Eric> failure.  Fail

Well, this just has to be another problem with
new_file_resolver_current_directory. I guess you are using Windows,
and file_system.current_working_directory is returning a drive letter
(though I still can't quite see what the problem might be).

Perhaps you could edit xm_resolver_factory.e and change:

	new_file_resolver_current_directory: XM_URI_EXTERNAL_RESOLVER is
			-- Resolver for "file:" scheme with default set
			-- to the current directory
		local
			a_uri: UT_URI
			a_string: STRING
		do
			a_string := STRING_.concat ("file://", file_system.current_working_directory)
			create a_uri.make (STRING_.concat (a_string, "/"))
			Result := new_file_resolver_with_uri (a_uri)
		ensure
			result_not_void: Result /= Void
		end

to

	new_file_resolver_current_directory: XM_URI_EXTERNAL_RESOLVER is
			-- Resolver for "file:" scheme with default set
			-- to the current directory
		local
			a_uri: UT_URI
			a_string: STRING
		do
			a_string := STRING_.concat ("file://",	file_system.current_working_directory)
                        print (a_string)
			create a_uri.make (STRING_.concat (a_string, "/"))
			Result := new_file_resolver_with_uri (a_uri)
		ensure
			result_not_void: Result /= Void
		end

which should be revealing, I hope.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
> Well, this just has to be another problem with
> new_file_resolver_current_directory. I guess you are using Windows,
> and file_system.current_working_directory is returning a drive letter

Yes, it does.

> Perhaps you could edit xm_resolver_factory.e and change:
> 
> 	new_file_resolver_current_directory: XM_URI_EXTERNAL_RESOLVER is
> 			-- Resolver for "file:" scheme with default set
> 			-- to the current directory
> 		local
> 			a_uri: UT_URI
> 			a_string: STRING
> 		do
> 			a_string := STRING_.concat ("file://", file_system.current_working_directory)
> 			create a_uri.make (STRING_.concat (a_string, "/"))
> 			Result := new_file_resolver_with_uri (a_uri)
> 		ensure
> 			result_not_void: Result /= Void
> 		end
> 
> to
> 
> 	new_file_resolver_current_directory: XM_URI_EXTERNAL_RESOLVER is
> 			-- Resolver for "file:" scheme with default set
> 			-- to the current directory
> 		local
> 			a_uri: UT_URI
> 			a_string: STRING
> 		do
> 			a_string := STRING_.concat ("file://",	file_system.current_working_directory)
>                         print (a_string)
> 			create a_uri.make (STRING_.concat (a_string, "/"))
> 			Result := new_file_resolver_with_uri (a_uri)
> 		ensure
> 			result_not_void: Result /= Void
> 		end
> 
> which should be revealing, I hope.

I got:

     file://C:\gobo\test\xml\xslt

My web browser (Netscape) accepts it and transforms it to:

     file:///C:%5Cgobo%5Ctest%5Cxml%5Cxslt

(see the extra / before C:). The following is also accepted unchanged:

     file:///C:/gobo/test/xml/xslt

Also note that Netscape CANNOT find the corresponding file
when I omit the C drive:

     file:///gobo/test/xml/xslt

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:


    Eric> I got:

    Eric>      file://C:\gobo\test\xml\xslt

    Eric> My web browser (Netscape) accepts it and transforms it to:

    Eric>      file:///C:%5Cgobo%5Ctest%5Cxml%5Cxslt

    Eric> (see the extra / before C:). The following is also accepted
    Eric> unchanged:

    Eric>      file:///C:/gobo/test/xml/xslt

    Eric> Also note that Netscape CANNOT find the corresponding file
    Eric> when I omit the C drive:

    Eric>      file:///gobo/test/xml/xslt

Well, this is clearly a problem.

The fact that netscape accepts an invalid URL and transforms it to
another invalid URL is somewhat entertaining, but irrelevant to our
problem.

The last form you display (the one that Netscape DOESN'T accept) is
the only valid URL.
Anyway, i think I'll leave Franck to ponder on that (I shall ponder
myself in the mean time).

And I'll wait until this is cleared up before addressing my original
problem (I can bypass it for now).
-- 
Colin Paul Adams
Preston Lancashire

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> Also note that Netscape CANNOT find the corresponding file
    Eric> when I omit the C drive:

    Eric>      file:///gobo/test/xml/xslt

That's seems odd to me.
What about:

file://C:/gobo/test/xml/xslt


-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
> The last form you display (the one that Netscape DOESN'T accept) is
> the only valid URL.

But how do we know whether the file is on C: or D:?

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> Also note that Netscape CANNOT find the corresponding file
>     Eric> when I omit the C drive:
> 
>     Eric>      file:///gobo/test/xml/xslt
> 
> That's seems odd to me.
> What about:
> 
> file://C:/gobo/test/xml/xslt

When I tried that, it added a third leading slash:

   file:///C:/gobo/test/xml/xslt

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    >> file://C:/gobo/test/xml/xslt

    Eric> When I tried that, it added a third leading slash:

    Eric>    file:///C:/gobo/test/xml/xslt

I think the solution is to translate the \ to /.
But we also need to add a / before the drive letter.
After checking that we are on windows, and a drive letter is present.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     >> file://C:/gobo/test/xml/xslt
> 
>     Eric> When I tried that, it added a third leading slash:
> 
>     Eric>    file:///C:/gobo/test/xml/xslt
> 
> I think the solution is to translate the \ to /.
> But we also need to add a / before the drive letter.
> After checking that we are on windows, and a drive letter is present.

For the translation from \ to /, one can do:

inherit

    KL_SHARED_FILE_SYSTEM

   s := unix_file_system.pathname_from_file_system (s, file_system)

no matter what operating system is used (although I'm not sure
what happens to the drive letter, it might disappear, which is
not what we want).

To test for Windows:

inherit

   KL_SHARED_OPERATING_SYSTEM

  if operating_system.is_windows then

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> For the translation from \ to /, one can do:

    Eric> inherit

    Eric>     KL_SHARED_FILE_SYSTEM

    Eric>    s := unix_file_system.pathname_from_file_system (s,
    Eric> file_system)

    Eric> no matter what operating system is used (although I'm not
    Eric> sure what happens to the drive letter, it might disappear,
    Eric> which is not what we want).

    Eric> To test for Windows:

    Eric> inherit

    Eric>    KL_SHARED_OPERATING_SYSTEM

    Eric>   if operating_system.is_windows then

Well:

1) I don't have a windows system, so I can't test this, and
2) This is Franck's code, not mine (well, I may have amended it, but
he wrote it).

Can you make these changes, and see if it cures this problem (thus
exposing my original problem), and then commit them if Franck is happy
with the solution?
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> For the translation from \ to /, one can do:
> 
>     Eric> inherit
> 
>     Eric>     KL_SHARED_FILE_SYSTEM
> 
>     Eric>    s := unix_file_system.pathname_from_file_system (s,
>     Eric> file_system)
> 
>     Eric> no matter what operating system is used (although I'm not
>     Eric> sure what happens to the drive letter, it might disappear,
>     Eric> which is not what we want).
> 
>     Eric> To test for Windows:
> 
>     Eric> inherit
> 
>     Eric>    KL_SHARED_OPERATING_SYSTEM
> 
>     Eric>   if operating_system.is_windows then
> 
> Well:
> 
> 1) I don't have a windows system, so I can't test this, and
> 2) This is Franck's code, not mine (well, I may have amended it, but
> he wrote it).
> 
> Can you make these changes, and see if it cures this problem (thus
> exposing my original problem), and then commit them if Franck is happy
> with the solution?

I have changed XM_RESOLVER_FACTORY.new_file_resolver_current_directory
as follows (already committed in CVS):

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	new_file_resolver_current_directory: XM_URI_EXTERNAL_RESOLVER is
			-- Resolver for "file:" scheme with default set
			-- to the current directory
		local
			a_uri: UT_URI
			a_string: STRING
			a_cwd: STRING
			a_pathname: KI_PATHNAME
			a_drive: STRING
		do
			a_cwd := file_system.current_working_directory
			if file_system /= unix_file_system then
				a_pathname := file_system.string_to_pathname (a_cwd)
				a_cwd := unix_file_system.pathname_to_string (a_pathname)
				a_drive := a_pathname.drive
				if a_drive /= Void then
					a_cwd := STRING_.concat (a_drive, a_cwd)
					a_cwd := STRING_.concat ("/", a_cwd)
				end
			end
			a_string := STRING_.concat ("file://", a_cwd)
			create a_uri.make (STRING_.concat (a_string, "/"))
			Result := new_file_resolver_with_uri (a_uri)
		ensure
			result_not_void: Result /= Void
		end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

but now I have another error due to the fact that the UT_URI
created from the result of this routine as its `path' attribute
set to:

   /C:/gobo/text/xml/xslt/

whereas I think that it should be:

   C:\gobo\test\xml\xslt\

or at least:

   C:/gobo/test/xml/xslt/

in order to be able to open the files based on this path.
But I don't have enough knowledge about URIs in order to
make the modifications myself into the class UT_URI.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> but now I have another error due to the fact that the UT_URI
    Eric> created from the result of this routine as its `path'
    Eric> attribute set to:

    Eric>    /C:/gobo/text/xml/xslt/

    Eric> whereas I think that it should be:

    Eric>    C:\gobo\test\xml\xslt\

    Eric> or at least:

    Eric>    C:/gobo/test/xml/xslt/

    Eric> in order to be able to open the files based on this path.
    Eric> But I don't have enough knowledge about URIs in order to
    Eric> make the modifications myself into the class UT_URI.

It certainly must NOT contain backslashes. That is an illegal
character in URIs.

but the backslashes could be escaped.
-- 
Colin Paul Adams
Preston Lancashire

>>>>> "Colin" == Colin Paul Adams <colin@...> writes:

>>>>> "Eric" == Eric Bezault <ericb@...> writes:
    Eric> but now I have another error due to the fact that the UT_URI
    Eric> created from the result of this routine as its `path'
    Eric> attribute set to:

    Eric> /C:/gobo/text/xml/xslt/

    Eric> whereas I think that it should be:

    Eric> C:\gobo\test\xml\xslt\

    Eric> or at least:

    Eric> C:/gobo/test/xml/xslt/

    Eric> in order to be able to open the files based on this path.
    Eric> But I don't have enough knowledge about URIs in order to
    Eric> make the modifications myself into the class UT_URI.

    Colin> It certainly must NOT contain backslashes. That is an
    Colin> illegal character in URIs.

    Colin> but the backslashes could be escaped.

However, I don't think it is necessary to do this escaping.
Simply remove the leading / from the path, iff it is followed by a
drive letter and the OS is windows, before attempting to open the
file.

-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> but now I have another error due to the fact that the UT_URI
>     Eric> created from the result of this routine as its `path'
>     Eric> attribute set to:
> 
>     Eric>    /C:/gobo/text/xml/xslt/
> 
>     Eric> whereas I think that it should be:
> 
>     Eric>    C:\gobo\test\xml\xslt\
> 
>     Eric> or at least:
> 
>     Eric>    C:/gobo/test/xml/xslt/
> 
>     Eric> in order to be able to open the files based on this path.
>     Eric> But I don't have enough knowledge about URIs in order to
>     Eric> make the modifications myself into the class UT_URI.
> 
> It certainly must NOT contain backslashes. That is an illegal
> character in URIs.

So, what is the attribute `path' in UT_URI? If it's not
a file system pathname (associated with the current URI)
then it should not be used as such when trying to open
the corresponding file on the underlying file system.

I think that we should know what it part or subparts of
the URI, and what is the associated pathname on the file
system when we trying to open the corresponding file.
If it's not what `path' in URI is about, and if there is
no other way to get this file system pathname from UT_URI
perhaps it should be added.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:
>>>>>>"Colin" == Colin Paul Adams <colin@...> writes:
>>>>>
> 
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
>     Eric> but now I have another error due to the fact that the UT_URI
>     Eric> created from the result of this routine as its `path'
>     Eric> attribute set to:
> 
>     Eric> /C:/gobo/text/xml/xslt/
> 
>     Eric> whereas I think that it should be:
> 
>     Eric> C:\gobo\test\xml\xslt\
> 
>     Eric> or at least:
> 
>     Eric> C:/gobo/test/xml/xslt/
> 
>     Eric> in order to be able to open the files based on this path.
>     Eric> But I don't have enough knowledge about URIs in order to
>     Eric> make the modifications myself into the class UT_URI.
> 
>     Colin> It certainly must NOT contain backslashes. That is an
>     Colin> illegal character in URIs.
> 
>     Colin> but the backslashes could be escaped.
> 
> However, I don't think it is necessary to do this escaping.
> Simply remove the leading / from the path, iff it is followed by a
> drive letter and the OS is windows, before attempting to open the
> file.

That's a hack. I'd rather prefer a clean solution. And again,
if `path' in UT_URI is supposed to be a file system pathname,
then it should have backslashes under Windows.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> So, what is the attribute `path' in UT_URI? If it's not a
    Eric> file system pathname (associated with the current URI) then
    Eric> it should not be used as such when trying to open the
    Eric> corresponding file on the underlying file system.

It depends upon the URI scheme.

Now we are dealing with the "file" scheme.
Which is a URL.
Parsing URLs, the authority field is delimited by // at the beginning,
and ends immediately prior to the first ? or / (the latter starts the
absolute path field, which ends immediately prior to the first ? or #).

So path must start with a /.

Quoting from RFC1738:

 A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

   For example, a VMS file

     DISK$USER:[MY.NOTES]NOTE123456.TXT

   might become

     <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

   As a special case, <host> can be the string "localhost" or the empty
   string; this is interpreted as `the machine from which the URL is
   being interpreted'.

   The file URL scheme is unusual in that it does not specify an
   Internet protocol or access method for such files; as such, its
   utility in network protocols between hosts is limited.


Now on unix systems, the leading / must be retained when attempting to
open the file.
On windows and VMS, clearly it must be dropped.

So I think we need to code this into the logic that opens the stream. 
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:

>  A file URL takes the form:
> 
>        file://<host>/<path>
...
> Now on unix systems, the leading / must be retained when attempting to
> open the file.
> On windows and VMS, clearly it must be dropped.

To me it looks like *nix path /usr/local/bin is to be translated into
file:///usr/local/bin. Windows path A:\autoexec.bat is to be
translated into file:///A:/autoexec.bat, while Windows UNC path
\\my_server\public\bin\format.exe is to be translated into
file://my_server/public/bin/format.exe.

Alexander Kogtenkov

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> So, what is the attribute `path' in UT_URI? If it's not a
>     Eric> file system pathname (associated with the current URI) then
>     Eric> it should not be used as such when trying to open the
>     Eric> corresponding file on the underlying file system.
> 
> It depends upon the URI scheme.
> 
> Now we are dealing with the "file" scheme.
> Which is a URL.
> Parsing URLs, the authority field is delimited by // at the beginning,
> and ends immediately prior to the first ? or / (the latter starts the
> absolute path field, which ends immediately prior to the first ? or #).
> 
> So path must start with a /.
> 
> Quoting from RFC1738:
> 
>  A file URL takes the form:
> 
>        file://<host>/<path>
> 
>    where <host> is the fully qualified domain name of the system on
>    which the <path> is accessible, and <path> is a hierarchical
>    directory path of the form <directory>/<directory>/.../<name>.
> 
>    For example, a VMS file
> 
>      DISK$USER:[MY.NOTES]NOTE123456.TXT
> 
>    might become
> 
>      <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
> 
>    As a special case, <host> can be the string "localhost" or the empty
>    string; this is interpreted as `the machine from which the URL is
>    being interpreted'.
> 
>    The file URL scheme is unusual in that it does not specify an
>    Internet protocol or access method for such files; as such, its
>    utility in network protocols between hosts is limited.
> 
> 
> Now on unix systems, the leading / must be retained when attempting to
> open the file.
> On windows and VMS, clearly it must be dropped.
> 
> So I think we need to code this into the logic that opens the stream. 

But the path as defined above is not the pathname that should
be used to open the file on the file system. On Windows and
VMS they should be translated to Windows or VMS pathnames before
opening the files.

Furthermore, as you already pointed out in a previous message,
the leading / should be dropped under Windows only if followed
by a drive letter. It should not be dropped when the corresponding
Windows pathnames are:

   \my_dir_under_the_default_drive

or:

   \\hostname\my_dir

which are likely to look like this in URI format (correct me
if I'm wrong):

   file:///my_dir_under_the_default_drive/
   file://hostname/my_dir/

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> But the path as defined above is not the pathname that
    Eric> should be used to open the file on the file system. On
    Eric> Windows and VMS they should be translated to Windows or VMS
    Eric> pathnames before opening the files.

    Eric> Furthermore, as you already pointed out in a previous
    Eric> message, the leading / should be dropped under Windows only
    Eric> if followed by a drive letter. It should not be dropped when
    Eric> the corresponding Windows pathnames are:

    Eric>    \my_dir_under_the_default_drive

    Eric> or:

    Eric>    \\hostname\my_dir

    Eric> which are likely to look like this in URI format (correct me
    Eric> if I'm wrong):

    Eric>    file:///my_dir_under_the_default_drive/
    Eric> file://hostname/my_dir/

I can't correct you, as I suspect you are right. I have no more
knowledge of this issue beyond the RFC that i have already quoted. Nor
have I been able to find anything more.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> But the path as defined above is not the pathname that
>     Eric> should be used to open the file on the file system. On
>     Eric> Windows and VMS they should be translated to Windows or VMS
>     Eric> pathnames before opening the files.
> 
>     Eric> Furthermore, as you already pointed out in a previous
>     Eric> message, the leading / should be dropped under Windows only
>     Eric> if followed by a drive letter. It should not be dropped when
>     Eric> the corresponding Windows pathnames are:
> 
>     Eric>    \my_dir_under_the_default_drive
> 
>     Eric> or:
> 
>     Eric>    \\hostname\my_dir
> 
>     Eric> which are likely to look like this in URI format (correct me
>     Eric> if I'm wrong):
> 
>     Eric>    file:///my_dir_under_the_default_drive/
>     Eric> file://hostname/my_dir/
> 
> I can't correct you, as I suspect you are right. I have no more
> knowledge of this issue beyond the RFC that i have already quoted. Nor
> have I been able to find anything more.

OK, so let's assume that the implementation of `path' in
UT_URI is correct (e.g. follows the standard with leading
slash, slash as separator, etc.). Then I think that the
bug is in XM_FILE_URI_RESOLVER.resolve. It shouldn't use
UT_URI path directly. Perhaps we should add a feature in
UT_URI to return a valid pathname of `path' for the
underlying platform/filesystem (which I initially thought
`path' was all about). I don't know what to call this feature.
`file_system_pathname' seems to verbose. Anyway, this is
this new feature that should be called by `resolve' in class
XM_FILE_URI_RESOLVER. Looking at the indexing clause of
XM_FILE_URI_RESOLVER, what about `local_pathname' or
`local_path' for this new feature? Any better idea?

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:


    Eric> OK, so let's assume that the implementation of `path' in
    Eric> UT_URI is correct (e.g. follows the standard with leading
    Eric> slash, slash as separator, etc.). Then I think that the bug
    Eric> is in XM_FILE_URI_RESOLVER.resolve. It shouldn't use UT_URI
    Eric> path directly. Perhaps we should add a feature in UT_URI to
    Eric> return a valid pathname of `path' for the underlying
    Eric> platform/filesystem (which I initially thought `path' was
    Eric> all about). I don't know what to call this feature.
    Eric> `file_system_pathname' seems to verbose. Anyway, this is
    Eric> this new feature that should be called by `resolve' in class
    Eric> XM_FILE_URI_RESOLVER. Looking at the indexing clause of
    Eric> XM_FILE_URI_RESOLVER, what about `local_pathname' or
    Eric> `local_path' for this new feature? Any better idea?

No. This seems to be a good idea. `local_pathname' seems slightly
better to me.

Looking again at the indexing clause, I think the description is
correct. That is, the local file system should be able to interpret
the `local_pathname' correctly, even if it happens to reside on another
machine.
As an example, if I had /usr on my system mounted read-only on an NFS
volume residing on another machine, then a request for
file:///usr/some-text.file would be treated as a local file request, 
and sucessfully opened (provided some-text.file exists in the root
directory of the volume where /usr is mounted from).
Likewise Windows UNC paths should be opened sucessfully.

I presume that browsers work like this (I don't run NFS here any
onger, so i can't test it out).

Although the RFC description seems to imply that access to files on
remote systems is possible using the file scheme and a non-local
authority name, I do not think any software actually implements
this. And there is a separate nfs scheme for remote file access. So I
think we should stick with XM_FILE_URI_RESOLVER modified to use `local_filename'.
-- 
Colin Paul Adams
Preston Lancashire

What about adding the following feature to UT_URI

    pathname : KL_PATHNAME is ...

Feature `pathname' could then be used to infer a local path.

Best regards,

Paul G. Crismer

Paul G. Crismer wrote:
> What about adding the following feature to UT_URI
> 
>    pathname : KL_PATHNAME is ...
> 
> Feature `pathname' could then be used to infer a local path.

Indeed, except that under Unix it means doing more work
than needed because UT_URI.path already has the good format.
What I had in mind was:

   local_pathname: STRING is
       local
           a_pathname: KI_PATHNAME
       do
           if file_system = unix_file_system then
               Result := path
           else
               a_pathname := do some work to get a KI_PATHNAME
               Result := file_system.pathname_to_string (a_pathname)
           end
       end

And of course my "do some work to get a KI_PATHNAME" would
be what you suggest for your new routine `pathname'.
Perhaps we should provide both routines. I don't know...

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:

> Although the RFC description seems to imply that access to files on
> remote systems is possible using the file scheme and a non-local
> authority name, I do not think any software actually implements
> this.

file://remote_machine/some_path

works on Windows (e.g., in (Internet) Explorer) and opens a file on a
remote machine.

Alexander Kogtenkov

Alexander Kogtenkov wrote:
> Colin Paul Adams wrote:
>>Although the RFC description seems to imply that access to files on
>>remote systems is possible using the file scheme and a non-local
>>authority name, I do not think any software actually implements
>>this.
> 
> file://remote_machine/some_path
> 
> works on Windows (e.g., in (Internet) Explorer) and opens a file on a
> remote machine.

But does that:

   file://remote_machine/A:/some_path

work?

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Eric Bezault wrote:
> Paul G. Crismer wrote:
> 
>> What about adding the following feature to UT_URI
>>
>>    pathname : KL_PATHNAME is ...
>>
>> Feature `pathname' could then be used to infer a local path.
> 
> Indeed, except that under Unix it means doing more work
> than needed because UT_URI.path already has the good format.
> What I had in mind was:
> 
>   local_pathname: STRING is
>       local
>           a_pathname: KI_PATHNAME
>       do
>           if file_system = unix_file_system then
>               Result := path
>           else
>               a_pathname := do some work to get a KI_PATHNAME
>               Result := file_system.pathname_to_string (a_pathname)
>           end
>       end
> 
> And of course my "do some work to get a KI_PATHNAME" would
> be what you suggest for your new routine `pathname'.
> Perhaps we should provide both routines. I don't know...

After a second thought, Paul's suggestion may be the right
thing to do if we go a little bit further. Although I don't
know thoroughly the implementation of UT_URI, perhaps it
might be rewritten in such a way that it has:

   pathname: KL_PATHNAME

as attribute (containing most of the information about
the URI in an internal format). Then the current `path'
feature (following the standard, with leading slash,
slashes as separator, etc.), and perhaps other existing
features of UT_URI, could be a function building the
string from the KL_PATHNAME attribute. We could keep
`local_pathname' as well:

   local_pathname: STRING is
       do
            Result := file_system.pathname_to_string (pathname)
       end

or let the client classes call the `pathname_to_string'
themselves as suggested by Paul.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> Then the current `path' feature
    Eric> (following the standard, with leading slash, slashes as
    Eric> separator, etc.), and perhaps other existing features of
    Eric> UT_URI, could be a function building the string from the
    Eric> KL_PATHNAME attribute.

I don't understand this. `path' MUST be the field between the
authority field and any fragment identifier or query string.

So this is known at URI parse time. Why try to calculate it from a KL_PATHNAME?
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> Then the current `path' feature
>     Eric> (following the standard, with leading slash, slashes as
>     Eric> separator, etc.), and perhaps other existing features of
>     Eric> UT_URI, could be a function building the string from the
>     Eric> KL_PATHNAME attribute.
> 
> I don't understand this. `path' MUST be the field between the
> authority field and any fragment identifier or query string.
> 
> So this is known at URI parse time. Why try to calculate it from a KL_PATHNAME?

As I said, I don't know very well the implementation of
UT_URI. But I thought that there was some parsing in
the creation routines. In that case, why not keep a
fully parsed data as internal representation? I don't
think that the standard tells us how to implement class
UT_URI. What it does is require that queries such as
`path' and others follow its rules, regardless of how
the information is kept internally.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:
> So this is known at URI parse time. Why try to calculate it from a KL_PATHNAME?

Because we don't want to keep duplicated information
in the same class, and KL_PATHNAME gives more
information than `path' because it has already
been cut into meaningful subparts.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Eric Bezault wrote:

> But does that:
> 
>    file://remote_machine/A:/some_path
> 
> work?

It could work if it would be possible for share name to have ':'.
But, I guess, share name cannot have ':'.

Alexander Kogtenkov

Eric Bezault:

> know thoroughly the implementation of UT_URI, perhaps it
> might be rewritten in such a way that it has:
> 
>    pathname: KL_PATHNAME
> 
> as attribute

I agree this is desirable. I considered something like 
this when reviewing UT_URI but there was a problem, which 
from memory I think was related with escaping (which is 
broken or left to the client currently) so escaping needs 
to be dealt with first or at the same time as making the 
path a list of items (both are in doc/xml/TODO.txt).

Franck Arnaud wrote:
> Eric Bezault:
>>know thoroughly the implementation of UT_URI, perhaps it
>>might be rewritten in such a way that it has:
>>
>>   pathname: KL_PATHNAME
>>
>>as attribute
> 
> I agree this is desirable. I considered something like 
> this when reviewing UT_URI but there was a problem, which 
> from memory I think was related with escaping (which is 
> broken or left to the client currently) so escaping needs 
> to be dealt with first or at the same time as making the 
> path a list of items (both are in doc/xml/TODO.txt).

I'm not sure I found the corresponding lines in TODO.txt.
But if you want to have a second (or third) look at the
design and implementation of UT_URI, you're welcome
because I'm not very confident about diving into that
code and I already have plenty of other things to do
these days.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
>     Eric> I looked at the code of hash table and I cannot see any
>     Eric> obvious problem, so I would need to be able to reproduce the
>     Eric> bug. Do you have a small example reproducing the bug?
> 
>     Colin> I have a test case that I'm working on. I could check the
>     Colin> code in.
> 
> OK. It's all checked in now.
> 
> You can reproduce the failure by changing to $GOBO/test/xml/xslt
> and running geant clobber; geant test_debug
> 
> I'm afraid this is by no means a small test, but it's all I have.

After hacking the code in my local copy of the code in order
to bypass the problems with the URI under Windows, the test
passed successfully and I didn't manage to get the error in
DS_HASH_TABLE when running with ISE:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\gobo\test\xml\xslt>geant test_debug_ise

Testing xslt...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

TODO: {XM_XSLT_PREPARED_STYLESHEET}.create_style_sheet_executable - 
literal result stylesheet facility is only partly written
TODO: {XM_XSLT_NUMBER_FORMATTER}.is_alphanumeric (does not use Unicode 
categories) is only partly written
TODO: {XM_XSLT_FORMAT_NUMBER}.check_arguments is only partly written
TODO: {XM_XSLT_STYLESHEET}.compile_stylesheet is only partly written
TODO: {XM_XSLT_FIXED_ELEMENT}.process_leaving_tail - use-attribute-sets 
is only partly written
TODO: {XM_XSLT_SEQUENCE_OUTPUTTER}.notify_characters is only partly written
TODO: {XM_XPATH_CURRENT_DATETIME}.evaluate_item needs to be written
TODO: {XM_XSLT_NUMBERER_EN}.formatted_string is only partly written
Test Summary for xslt

# PASSED:     2 tests
# Failed:     0 test
# Aborted:    0 test
# Total:      2 tests (110 assertions)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do you still have the error when running the test yourself?

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:


    Eric> After hacking the code in my local copy of the code in order
    Eric> to bypass the problems with the URI under Windows, the test
    Eric> passed successfully and I didn't manage to get the error in
    Eric> DS_HASH_TABLE when running with ISE:

No. As I have commented out the line that results in the problem.

I don't know whether or not the latest check in copy has the line
commentted in or out.

If you look in xm_xslt_test_transform.e, there is a line:

a_transformer.register_document (a_document,another_uri_source.system_id)

If this is commented out, then please try un-commenting it, to see if
you get the error or not (I can't compile myself at the moment, due to
to some changes I am making elsewhere, but I've uncommented the line
now, so when i get a clean compile again, I'll find out).
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
> 
>     Eric> After hacking the code in my local copy of the code in order
>     Eric> to bypass the problems with the URI under Windows, the test
>     Eric> passed successfully and I didn't manage to get the error in
>     Eric> DS_HASH_TABLE when running with ISE:
> 
> No. As I have commented out the line that results in the problem.
> 
> I don't know whether or not the latest check in copy has the line
> commentted in or out.
> 
> If you look in xm_xslt_test_transform.e, there is a line:
> 
> a_transformer.register_document (a_document,another_uri_source.system_id)
> 
> If this is commented out, then please try un-commenting it, to see if
> you get the error or not (I can't compile myself at the moment, due to
> to some changes I am making elsewhere, but I've uncommented the line
> now, so when i get a clean compile again, I'll find out).

OK, I get the error now.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

Colin Paul Adams wrote:
>>>>>>"Eric" == Eric Bezault <ericb@...> writes:
>>>>>
> 
>     Eric> I looked at the code of hash table and I cannot see any
>     Eric> obvious problem, so I would need to be able to reproduce the
>     Eric> bug. Do you have a small example reproducing the bug?
> 
> I have a test case that I'm working on. I could check the code in.
> 
>     Eric> Also, are you sure that the hash_code of your keys does not
>     Eric> change between the time you insert objects in the hash table
>     Eric> and the time you call `has'?
> 
> I've checked trough this - the answer is Yes.

I'm afraid the answer in No. In XM_XPATH_TREE_DOCUMENT the
`hash_code' is based on `document_number'. But in routine
`make' of this class `document_number' is assigned after
the Current document has been inserted in the hash table
`document_number_map' of class XM_XPATH_NAME_POOL. Therefore
the `hash_code' of the keys in `document_number_map' change
between the time you insert the items and the time you query
them calling XM_XPATH_NAME_POOL.is_document_allocated (which
itself calls `document_number.has').

I think that you have to review your design in such a way that
either the hash code is not based on `document_number', or
`document_number' is given a number before inserting the document
as a key into the hash table. Here is one way of doing it:

In XM_XPATH_NAME_POOL:

	is_document_allocated (a_doc: XM_XPATH_DOCUMENT): BOOLEAN is
			--	Is a document number associated with `a_doc'
		require
			document_not_void: a_doc /= Void
		do
			Result := a_doc.document_number /= 0
		end

	allocate_document_number (a_doc: XM_XPATH_DOCUMENT) is
			-- Add a document to the pool, and allocate a document number.
		require
			document_not_void: a_doc /= Void
			document_not_allocated: not is_document_allocated (a_doc)
		do
			if documents.is_full then
				documents.resize (2 * documents.count)
			end
			a_doc.set_document_number (documents.count + 1)
			document_numbers.put_last (a_doc)
		ensure
			document_allocated: is_document_allocated (a_doc)
		end

	document_number (a_doc: XM_XPATH_DOCUMENT): INTEGER is
			-- Document number associated with `a_doc'
		require
			document_not_void: a_doc /= Void
			document_is_allocated: is_document_allocated (a_doc)
		do
			Result := a_doc.document_number
		ensure
			document_number_positive: Result >= 1
		end

(XM_XPATH_DOCUMENT should be exported only to XM_XPATH_NAME_POOL
so that it is not accessed directly if not allocated yet.)

and replace:

	document_number_map: DS_HASH_TABLE [INTEGER, XM_XPATH_DOCUMENT]

by:

	documents: DS_ARRAYED_LIST [XM_XPATH_DOCUMENT]


In XM_XPATH_TREE_DOCUMENT:

feature {XM_XPATH_NAME_POOL} -- Setting

	set_document_number (a_number: INTEGER) is
			-- Set `document_number' to `a_number'.
		do
			document_number := a_number
		ensure
			document_number_set: document_number = a_number
		end


In XM_XPATH_TREE_DOCUMENT:

	make (a_name_pool: XM_XPATH_NAME_POOL; a_system_id: STRING) is
			-- Establish invariant.
		require
			name_pool_not_void: a_name_pool /= Void
			system_id_not_void: a_system_id /= Void
		do
			document := Current
			node_type := Document_node
			create children.make (5)
			create system_id_map.make
			sequence_number_high_word := 1
			name_pool := a_name_pool
			set_system_id (a_system_id)
			name_pool.allocate_document_number (Current)
		ensure
			name_pool_set: name_pool = a_name_pool
			base_uri_set: STRING_.same_string (base_uri, a_system_id)
		end

In XM_XPATH_TEXT_FRAGMENT_VALUE:

	make (a_value, a_system_id: STRING; a_name_pool: XM_XPATH_NAME_POOL) is
			-- Establish invariant.
		require
			value_not_void: a_value /= Void
			system_id_not_void: a_system_id /= Void
			name_pool_not_void: a_name_pool /= Void
		do
			text := a_value
			system_id := a_system_id
			name_pool := a_name_pool
			name_pool.allocate_document_number (Current)
		ensure
			text_set: text = a_value
			system_id_set: system_id = a_system_id
			name_pool_set: name_pool = a_name_pool
		end


In XM_XPATH_TINY_DOCUMENT:

	make (an_estimated_node_count: INTEGER; an_estimated_attribute_count: 
INTEGER; an_estimated_namespace_count: INTEGER; 
an_estimated_character_count: INTEGER; a_name_pool: XM_XPATH_NAME_POOL; 
a_system_id: STRING) is
			-- Establish invariant
		require
			positive_node_count: an_estimated_node_count > 0
			attribute_count: an_estimated_attribute_count >= 0
			namespace_count: an_estimated_namespace_count >= 0
			character_count: an_estimated_character_count >= 0
			name_pool_not_void: a_name_pool /= Void
			system_id_not_void: a_system_id /= Void
		do
			root_node := 1
			node_number := 1
			document := Current
			node_type := Document_node

			create system_id_map.make
			create node_kinds.make (1, an_estimated_node_count)
			create depth.make (1, an_estimated_node_count)
			create next_sibling_indices.make (1, an_estimated_node_count)
			create alpha.make (1, an_estimated_node_count)
			create beta.make (1, an_estimated_node_count)
			create name_codes.make (1, an_estimated_node_count)

			create attribute_parents.make (an_estimated_attribute_count)
			create attribute_codes.make (an_estimated_attribute_count)
			create attribute_values.make (an_estimated_attribute_count)
			attribute_values.set_equality_tester (string_equality_tester)
			
			create namespace_parents.make (an_estimated_namespace_count)
			create namespace_codes.make (an_estimated_namespace_count)

			name_pool := a_name_pool
			set_system_id (a_system_id)
			name_pool.allocate_document_number (Current)
		ensure
			name_pool_set: name_pool = a_name_pool
			--base_uri_set: STRING_.same_string (base_uri, a_system_id)
		end


One difference with the current implementation is that
in XM_XSLT_TRANSFORMER.register_document `a_documentation'
will have its `document_number' set whereas this was not the
case before.

The other difference is that a documentation cannot belong
only to one XM_XPATH_NAME_POOL. The current implementation
appreantly did not forbid allocating a document number for
the same document but in two XM_XPATH_NAME_POOL, however
doing that would have led to catastrophy (corrupting even
more the hash table and probably other things by having
`document_number' changing its value depending on the
XM_XPATH_NAME_POOL considered).

If it was intended that a doc could be part of several
XM_XPATH_NAME_POOL, then the suggested code above will
not work, and you have still to find a better design to
implement your existing code, probably by implementing
`hash_code' so that it is not based on `document_number'
(whose meaning is confusing to me if a doc can belong
to more than one XM_XPATH_NAME_POOL) but on something
else whose value does not change over time.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> Also, are you sure that the hash_code of your keys does not
    Eric> change between the time you insert objects in the hash table
    Eric> and the time you call `has'?
    >> I've checked trough this - the answer is Yes.

    Eric> I'm afraid the answer in No.

Sorry about that. I must have inserted by print statement at the wrong
place when debugging.
Thanks for all your work on this.

    Eric> The other difference is that a documentation cannot belong
    Eric> only to one XM_XPATH_NAME_POOL.

That's not a problem.
In fact, at the moment, there is only one, shared, name pool (I intend to
insert invariants and pre-conditions all over the place soon, to
confirn this, with a view to making all references direct to the
shared name pool, rather than passing the name pool as a parameter
everywhere).

I only envisage using of multiple name pools for pre-compiled
stylesheets. When a compiled stylesheet is loaded into memory, then
the name pool that was used when it was compiled needs to be loaded
into memeory too, and set to be the shared name pool.

But I think pre-compiled stylesheets (stored in the file system, or a
database, or somewhere), although a useful performance feature , is a
rather distant prospect, as we do not have a STORABLE facility in
Gobo.

PROGRESS REPORT

Changing the subject a little, I have nearly finished the code
necessary to transform books.xml with books.xsl to yield html.
These files are in $GOBO/test/xml/xpath/data, and are slightly
modified versions of samples that come with Saxon 8.0.
Books.xsl is an XSLT 2.0 stylesheet, and makes use of
xsl:for-each-group - a really wonderful feature which makes 
Muenchian grouping using keys - which was necessary in XSLT 1.0,
but very awkward, completly uncessary. I have already got this
working.

The situation so far:
I am able to perform the transform to xml (rather than html), although
a few things are not quite implemented yet (mostly number formatting).
I am writing the HTML and XHTML serializers today, and I would hope that I can
achieve identical result to saxon 8.0 within 2 weeks.

then I shall switch to tackling the gobo2html.xsl. I would hope to be
able to sucessfully transform all existing documentation by the end of
September.
I shall do this by implementing just those features that are necessary
for these particular transformations. 
Not that this approach does not guarantee that any new documentation
will necessarily transform sucessfully, but I think it will be useful
if the next version of gobo can compile all of it's documentation at
install time (the only question mark is VE because of the problem with
invariants and MA_DECIMAL, but that should be circumventable simply be
building a version of gexslt without invariant checking - I've not
tried this test yet).
Do you have a projected release date for the next version of Gobo? 
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams wrote:
> then I shall switch to tackling the gobo2html.xsl. I would hope to be
> able to sucessfully transform all existing documentation by the end of
> September.

Great.

> Do you have a projected release date for the next version of Gobo? 

Not yet.

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com