Re: SGML entity mgmt stds (was Re: ISUG and DSSSL)

[Cees de Groot <cg@xxxxxxxxxxxx>]

Didier said:
>I do not have the same structure as specified in this document but I do not
>see any problem to adapt to it. It seems that the proposed structure is:
>
>SGML
>  |__ DTD
>  |__ entity
>  |__ Stylesheet
>  |__ misc
>
where, under Unix at least (the primary target of the propsal), we would have
all the names in lowercase. 

>I would have only one reserve about the "stylesheet" directory. I would call
>that "scripts" instead because it may be also other thing than strict
>stylesheet scripts. 

SGMLtools stores its (Python) scripts under misc/sgmltools. The rationale 
behind this is that {dtd,entity,stylesheet} are all "core" SGML thingies,
which in a certain sense "belong" to the processing system, are accessed
through catalogs, etcetera. 

>What about a "library" section in addition to the one listed above. The
>library section could contain all lib scripts (like for instance the
>Mulberry lib).
>
I'd make an entry under stylesheet/

>The referred document do not have a dir for catalogs. this seems to be an
>omission. My suggestion would be to have this structure (includes the one
>from the referred doc)
>
Personally, I like catalogs to stick with the stuff they're catalogueing. It
is easier to maintain (because typically stuff is distributed in a single
directory including a catalog file, so "make install" is just a flat
copy), and with the help of some - in the case of the SGML on Unix
standard - symlink magic it is very easy to maintain.

Say, you have a couple of catalogs:
/usr/share/sgml/
    stylesheets/docbook/catalog
                sgmltools/sgmltools.cat
    dtd/jade/dsssl.cat
        docbook/3.0/docbook.cat

etcetera. Under the system as currently implemented by SGMLtools, we make
symbolic links to these catalogs from a directory /etc/sgml/catalog.d:

/etc/sgml/catalog.d/dsssl.cat -> /usr/share/sgml/dtd/jade/dsssl.cat
                    sgmltools.cat ->
		    /usr/share/sgml/stylesheets/sgmltools/sgmltools.cat

etcetera. For every catalog file that we want to have accessible by default,
we have a single symlink. A simple script, that needs to be re-run when
a catalog file is added, reads all the symlinks and generates a script that
sets the environment variable SGML_CATALOG_FILES to refer to these
catalogs. Inclusion of this script in /etc/profile makes everything
available to the end user.

The Win32 equivalent would be to have a set of registry values pointing
to the catalog files under, say, D:\SGML\..., and have a script that walks
the registry and writes back a value for SGML_CATALOG_FILES to the default
system environment.

Note that in SGMLtools I've added another layer of indirection for specifying
DSSSL scripts: aliases. In a file /etc/sgml/aliases or ~/.sgmlaliases you
can have a list of alias->pubid[#stylesheet] mappings:

dbprint "-//Norman Walsh//DOCUMENT DocBook Print Stylesheet//EN"
myprint /usr/local/share/sgml/mine/print.dsssl
sgmltools-ps "-//SGMLtools//DOCUMENT Docbook Style Sheet for Print//EN"#print

etcetera. A user can specify a stylesheet on the SGMLtools command line
via the alias, saving a lot of typing work...



-- 
Cees de Groot               http://www.cdegroot.com     <cg@xxxxxxxxxxxx>
                            http://www.sgmltools.org   <cg@xxxxxxxxxxxxx>


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist