Article View: comp.text.sgml
Article #156Re: Path Specification in External Entity Declarations
From: Erik Naggum
Date: Wed, 26 Aug 1992 19:46
Date: Wed, 26 Aug 1992 19:46
52 lines
3095 bytes
3095 bytes
Eliot,
I think the problems you have (and must have in any heteregenous
environment) speak out for using (formal) public identifiers, and let
the entity manager worry about where the files are located and what
they're named, if files they be.
My solution to this problem has been presented in this newsgroup (see
article <23243A@erik.naggum.no> in the archive), and includes using a
special (non-SGML) markup declaration at the head of all entities both
in storage and in transit which makes each file self-identifying with
respect to its formal public identifier. This markup declaration is not
passed to the SGML parser, but is eaten by the entity manager. A
special program prepares a file (e.g. entities.dir) which contains a
mapping between formal public identifier (from scanning the file), and
the file name (from the file system) in each directory. Using a list of
directories (path) in an environment-like variable, the entity manager
read these files at start-up, and public text entities can then be
retrieved with a minimum of fuss.
E.g., a file can start with the following "public text identification
declaration" (not an SGML term), and can have any random name it wants,
because the entity manager will use the mapping table, and not the file
name.
<!PUBLIC "-//Erik Naggum//DOCUMENT Richtext and SGML (v4)//EN">
Note that by using the "unregistered owner identifier" prefix, "-//",
you can use formal public identifiers without bothering with getting a
full registration according to ISO 9070. (Having an ISBN publisher
number helps organize things, though.)
Also note that system identifiers cannot be expected to work when you
export the document, and may have to be changed for a number of reasons.
A formal public identifier can stay the same because it's a string drawn
from a known and limited character set (minimum data).
I regard system identifiers on par with processing instructions in
cluttering up things, but see that they could be useful on occasion, and
should thus not be deprecated unconditionally. I also think all public
identifiers should be formal public identifiers.
Conclusion: public identifiers were designed to solve this problem, and
does.
Best regards,
</Erik>
--
Erik Naggum | ISO 8879 SGML | +47 295 0313
| ISO 10744 HyTime |
<erik@naggum.no> | ISO 10646 UCS | Memento, terrigena.
<enag@ifi.uio.no> | ISO 9899 C | Memento, vita brevis.
Technical Details
Message-ID:
<23320E@erik.naggum.no>Path:
arc1-ca.pugleaf.net!sparky!uunet!pipex!unipalm!uknet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!SGMLReferences:
<9208242114.AA13720@ucbvax.Berkeley.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!unipalm!uknet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!SGML From: SGML@ifi.uio.no (Erik Naggum) Newsgroups: comp.text.sgml Subject: Re: Path Specification in External Entity Declarations Summary: If you use system identifiers, you ask for problems. These problems disappear if you use (formal) public identifiers. Message-ID: <23320E@erik.naggum.no> Date: 26 Aug 92 19:46:19 GMT References: <9208242114.AA13720@ucbvax.Berkeley.EDU> Organization: Department of Informatics, University of Oslo, Norway Lines: 47