Re: [xsl] xslt create a variable from external xml file

Subject: Re: [xsl] xslt create a variable from external xml file
From: "Peter Flynn peter@xxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 28 Aug 2023 12:02:21 -0000
On 28/08/2023 12:36, LEGAULT, PHILLIP plegault@xxxxxxxxxx wrote:
Thanks everyone for your help.

By way of an obiter dictum, I have appended what I used to tell students about running *any* software likely to need to open all sorts of files.

The reason I have used "should" or "probably" reflects the pre-XML mess
of trying to guess where SGML software was looking for resolution of
external file entities, external DTD subsets, or even for the CATALOG
file itself. Those days are fortunately long behind us.

I would be interested to know if any of these still cause users trouble
when executing parsers, validators, IDEs, processors, etc.

Peter

=========================================================================

1. If you run the program from the command line, it will probably take
   with it the context of the directory where you typed the command;

2. If you run the program by clicking on an icon (desktop/toolbar/panel
   /dock), it will probably take with it the context of your login
   (home) directory UNLESS the icon's "Launch In..." setting was
   modified;

3. If you cause the program to run by clicking on the file you want to
   process, it will probably acquire the context directory of that file;

4. If you run the program by some other means like a "Process" button in
   an editor, IDE, control panel, web browser, etc, then all bets are
   off because there will probably be some directory configuration
   option that you set up (and that you can find out or change).

Note:

a. Files with relative paths will probably be opened relative to the
   execution directory in [1b4].

b. Files with absolute paths or file:// URIs (or indeed any URI) should
   be opened correctly.

c. Files with OS-specific paths like Hard Disk:System,
   /usr/share/doc, or C:/Program Files/foo should be regarded as errors
   or breakage-points and avoided.

=========================================================== 1998-04-16

Current Thread