sgml-base-doc-1.99.2/0000755000000000000000000000000012763406467011136 5ustar sgml-base-doc-1.99.2/EXPLANATIONS.lsb0000644000000000000000000002417012763406467013551 0ustar Explanantions of the recommendations to LSB ------------------------------------------- Introduction ------------ This document explains the choices that have been made for the recommendations to LSB about DocBook. This is presented in a separate document to leave the draft concentrate only on the "what?" and not on the "why?" There are hundreds of man-hours behind those recommendations. They really costed blood, sweat and tears. Each line was discussed many times and the global architecture changed quite often. We really tried to hear what everyone add to say. So we would like to encourage LSB in being very careful if they want to modify them. The general philosophy was to keep the "historical" choices everywhere it had no consequences, and the "best" technical choice wherever it was interesting. We have attempted to design a very simple but also powerful architecture, in full respect of the FHS (File system Hierarchy Standard). Another general principal of design was to think to the user, not to the theory. There were many models that would have been much more intellectually satisfactory - but they were all too complex for everyday's use. Definitions ----------- Why those definitions? Because we realized we were speaking about different things with the same words. An example is "SGML application": it can both refer to a specific DTD, or to a computer program meant to process some SGML or XML document, both definitions being perfectly correct. To avoid any potential confusion, we just chose the one we needed. Some definitions like "helper", "backend" and "frontend" are not even necessary to read the rest of the document. We left them because we needed them to provide a reference implementation. R001 - SGML Directory layout ---------------------------- Some existing projects were putting files in /usr/lib/sgml, some other in /usr/local/share/sgml. Those files are not libraries nor local to a system, so we chose /usr/share/sgml. Some projects used to put centralized catalogs at the same place as the other catalogs. Since they can be seen as system configuration files, it was locgical to centralize them in /etc. One very hard question was: should we separe sgml from xml? The relationship between one and the other is very strong, so we chose to keep them at the same place in the directory tree. This allows, for example, to have all docbook stuff, both sgml and xml, at the very same place, which is obviously practical. While /usr/share/sgml does not explicitely reflect this, we found that it was still better than /usr/share/markup (what about TeX then?), than /usr/share/ml or than other proposals. Why having fixed file paths while you could have got them from some configuration variables, autoconf mechanisms, etc? First because it's simpler: we wanted a very strong standard, given that the tools may still use such configuration variables or autoconf mechanisms to adapt to non-LSB platforms. We considered that a standard that does not specify enough is somehow encouraging the most bizarre variations. We chose a dtd-and-package-oriented architecture, instead of a file-type-oriented structure. This was probably the most controversial issue. The "natural" proposal for SGML and XML specialists is to have the FPIs map almost letter-per-letter in the directory names. However, this approach does not take profit of the catalogs mechanism that allow to map FPIs into file paths. A file-type-oriented architecture would have lead things like: /usr/share/sgml/USA-DOD/DTD_Table_Model_951010/EN/ /usr/share/sgml/OASIS/DTD_DocBook_V3.1/EN/ /usr/share/sgml/OASIS/ELEMENTS_DocBook_Information_Pool_V3.1/EN/ /usr/share/sgml/OASIS/ELEMENTS_DocBook_Document_Hierarchy_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Additional_General_Entities_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Notations_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Character_Entities_V3.1/EN/ or something more far away from the FPIs like: /usr/share/sgml/sgml-dtd/hal/docbook/2.4/ /usr/share/sgml/sgml-dtd/davenport/docbook/3.0/ /usr/share/sgml/sgml-dtd/davenport/docbook/3.0/ /usr/share/sgml/sgml-dtd/oasis/docbook/3.1/ /usr/share/sgml/xml-dtd/oasis/docbook/4.0/ /usr/share/sgml/dssl-stylesheets/nwalsh/docbook/3.1/ /usr/share/sgml/xsl-stylesheets/nwalsh/docbook/4.0/ /usr/share/sgml/sgml-dtd/ietf/html/2.0/ /usr/share/sgml/sgml-dtd/w3c/html/3.2/ but in all the case, the files would have been spread according to their file types in distant directories. We would probably have had entities somewhere, stylesheets somewhere else, dtds in a third place, and sgml declarations in a fourth place. This would certainly have broke some relative paths, and required more packaging work. The user does not think in terms of file types, whereas SGML specialists do. The user only thinks "I want to do some MathML" or "I want to do some XHTML" or "I want to do some TEI". This is why the basic unit is the DTD. This DTD-centered approach does not mean that first level directories are for DTDs. It just means that they hold everything related to a given DTD: stylesheets, enterprise-wide customizations, etc... R002 - DocBook Directory layout ------------------------------- Maybe the document seems confused because it mixes recommendantions for SGML and XML with recommendations for DocBook. It would somehow have been good to separate it into two documents. On the other hand, this allowed to think in very practical terms. There is only one lower level of directories. The directory names are vaguely defined as holding one "package". One advantage is that the relation to any RPM or DEB package is very close. The other advantage is that we have a very flat tree, thus easing both hacking, packaging and maintenance by system administrators. The lower level directories are version-numbered. This unusual naming scheme is intended to permit documents that are written using several versions of the same DTD to coexist on the same system. R003 - Open Catalog usage for SGML ---------------------------------- Why focusing so much on catalogs in these recommendations? Because they are the key to your directory structure and give a strong working infrastructure that every SGML or XML tool can count on. Open catalogs have very often been resented because they lead to problems like conflicting SGMLDECLs. However, those problems do not appear if you use them carefully. One of the keys is to avoid putting everything in the same bag, and to have centralized catalogs that are specific to a given DTD. The fact that they are DTD-specific has a number of advantages: - avoid SGMLDECL conflicts without assuming DTDDECL or DELEGATE support, which many tools still not support yet - avoid duplicate FPI declarations - allow to point to the right version of a given DTD and to the corresponding entities and style sheets from only one place When splitting your CATALOG pointers in one file per DTD, you also somehow lose a global vision on all the catalogs that are installed on your system. This is why we have introduced the super-catalog, pointing to all the centralized catalogs on your system. It eases a lot scripting issues. The super catalog may be used as a default centralized catalog, for example when the DTD is not known, however it can't be guaranteed that there won't be any declaration conflicts if an application chooses to use this functionality. OASIS says that all the catalogs should be named "CATALOG" or "catalog". This was impossible to respect in /etc/sgml where you will have the centralized catalogs, because many files cannot hold the same name. Somehow it does not break those directives that much, because all the ordinary catalogs on your system would still be named "catalog". We also choose to specify "catalog" rathen than "CATALOG", while OASIS leaves the choice. We considered that we should encourage one of both versions, whichever it should be, because it made live simpler for everyone (scripts, maintainers, packagers, tools authors, ...). In this respect, LSB implementations could be considered as conformant to OASIS, while the contrary would not be true. R004 - Open Catalog usage for DocBook ------------------------------------- Directories like the ones holding Jade's or OpenJade's declarations and the ISO entities are on top level because they are not specific to any given DTD and can be used by two or more of them. Of course one may argue that Jade's or OpenJade's declarations contain the document type definition of what DSSSL is. But again what is important is the usage, not the formal definition, so it has no reason to go to a dsssl/ directory (which would also encourage packagers to put the stylesheets in, away from their dtd, which is not what we want). R005 - Configuration files -------------------------- This recommendation is voluntarily vague, to ease as much as possible the possibility to create SGML applications with not creativity restrictions with respect to configuration files - the catalog layout solves anyhow one of their major problems: find the files. R006 - Iso-entities ------------------- So far, the most confusion has been with the file names holding these very basic character entities. We have seen the following naming schemes: ISOamsa ISOamsb ... ISOamsa.ent ISOamsb.ent ... iso-amsa iso-amsb ... iso-amsa.gml iso-amsb.gml ... etc... There was a similar confusion for the Formal public identifiers describing these files. We have seen the following naming schemes: "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" "ISO 8879-1986//ENTITIES Added Math Symbols: Arrow Relations//EN" Again, we chose to avoid deciding not to decide. We had a lot of feedback from users suffering from this indecision. Even if technical workarounds exist, we would like to encourage one of these forms to emerge. R007 - Packages --------------- We are very far from providing inter-distribution compatibility at the package level, and it is likely that someone will get broken dependencies if he/she mixes packages coming from different distributions. This document will not try to fix package names nor proposed dependency declarations for DocBook distributions. We however wanted to point out a problem that may be encountered when packaging SGML or XML: the package numbering scheme. sgml-base-doc-1.99.2/RECOMMENDATIONS.lsb0000644000000000000000000002420112763406467014066 0ustar Recommendations for DocBook, SGML and XML processing ---------------------------------------------------- Introduction ------------ In a normalisation effort, about thirty people, including packagers of some Linux distributions, and developers of SGML related tools such as the SGML-Tools and DocBook Tools project, discussed informally and agreed on a series of recommendations that will be submitted as a draft to the Linux Standard Base project. A reference implementation will also be done as part of the DocBook-tools project. This document's redaction started as an attempt to end the nightmare of DocBook distributions, but it appeared quickly to be generic enough to apply to any SGML or XML DTD. Explanations about the reasons for all our choices are given in a separate document. Following a list of definitions, you will find a set of recommendations: R001 - SGML Directory layout R002 - DocBook Directory layout (standard names for directories, their contents) R003 - Open Catalogs usage for SGML R004 - Open Catalogs usage for DocBook (for the centralized catalogs and for the individual catalogs) R005 - Configuration files (other /etc/sgml files) R006 - ISO-entities (file names and FPI declarations) R007 - Packages (how to package this type of material) We'd like to thank the following people who have participated intensively in this normalisation effort: Camille Begnis (MandrakeSoft) <camille@mandrakesoft.com> Eric Bischoff (Caldera, KDE) <eric@caldera.de> Karl Eichwalder (SuSE) <ke@suse.de> Mark Galassi (DocBook-tools) <rosalia@lanl.gov> Jorge Godoy (Conectiva) <godoy@conectiva.com.br> Cees de Groot (SGML-tools) <cg@cdegroot.com> Jochem Huhmann <joh@revier.com> David Mason (RedHat, Gnome) <dcm@redhat.com> Manoj Srivastava (Debian) <srivasta@datasync.com> Norman Walsh (Sun, OASIS) <ndw@nwalsh.com> and all the other many people that helped with their own contribution. Definitions ----------- In the scope of this document, we will use the following terms: SGML application: Any program used to view, edit, convert, process or apply any kind of treatment to a document written using a SGML or XML DTD (Document Type Definition). This includes command-line utilities as well as GUI-based applications. SGML converter: A SGML application, or a part of a bigger SGML application, used to convert from a given SGML-based input format to a given output format. frontend: A part of a SGML converter used to analyse the input format backend: A part of a SGML converter used to analyse the output format helper: A stand-alone application used by a SGML converter to accomplish the conversion itself. Style sheets: Declarations or scripts that define formatting during the conversion process. They can be written in any style sheets language: DSSSL, FOSIs, XSL, ... Open Catalog: A set of directives defined by OASIS, mostly used for defining equivalences between FPIs (Formal Public Identifiers) and real file names (see TR9401:1997 on http://www.oasis-open.org). Centralized catalog: An Open Catalog that includes only comments and CATALOG directives pointing to other catalogs (or DELEGATE directives if supported). Super catalog: An Open Catalog pointing to all the centralized catalogs. Package: A set of files assembled together for distribution. It includes RPMs, DEBs and any other kind of packaging system. R001 - SGML Directory layout ---------------------------- /etc/sgml/ Configuration files, including centralized catalogs. It includes: *.conf: generic configuration files sgml-docbook.cat, tei.cat, ...: DTD-specific centralized catalogs catalog: the super catalog ... /usr/share/sgml/ Architecture-independent files used by SGML applications: Open Catalogs (not the centralized ones), DTDs, entities, style sheets, and other declarative files, if any. It is organized into DTD-specific subdirectories: docbook/ tei/ html/ ... At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /usr/share/xml and /etc/xml. R002 - DocBook Directory layout ------------------------------- This is the layout for a Jade-based or an Openjade-based system. DocBook applications based on other parsers, or even any other SGML application, can be based on this layout as well. In /usr/share/sgml, the upper level directories identify the DTD that is concerned. Things that are not DTD-specific go directly into /usr/share/sgml under their own directory. The lower level directories are package-related. They are also version-numbered. /usr/share/sgml/ sgml-iso-entities-8879.1986/ xml-iso-entities-8879.1986/ (the ISO entities) jade-1.2.1/ openjade-1.3/ ... (the parsers and DSSSL engines architecture-independent files) ... /usr/share/sgml/docbook/ sgml-dtd-3.1/ sgml-dtd-4.0/ xml-dtd-4.0/ (the DocBook DTD) dsssl-stylesheets-1.54/ xsl-stylesheets-1.12/ (DSSSL style sheets for DocBook) kde-customization-0.1/ gnome-customization-0.1/ ldp-customization-0.1/ (customized DTDs, entities and style sheets for the various projects) ... (version number examples are arbitrary in this list) R003 - Open Catalog usage for SGML ---------------------------------- Open Catalog files include: - the individual catalogs provided with the DTDs, sylesheets or entities. - the centralized catalogs used as central source of information that is specific to docbook, tei, or any other DTD - the super catalog that references indirectly all the available catalog files The centralized catalog file names must end in .cat and reside in /etc/sgml. They contain only comments and CATALOG directives pointing to the "real" catalogs, like: -- sample contents of /etc/sgml/foo-1.05.cat -- CATALOG /usr/share/sgml/foo/xml-dtd-1.05/catalog CATALOG /usr/share/sgml/foo/xsl-stylesheets-0.1/catalog One can use DELEGATE instead of CATALOG if this directive is known to be supported. The centralized catalogs are DTD-specific and can be version-numbered. Here are examples of such centralized catalogs: /etc/sgml/ sgml-docbook.cat sgml-docbook-3.1.cat sgml-docbook-4.0.cat xml-docbook-4.0.cat Version-less centralized catalogs could be only symbolic links to the latest version (or to any other older version). /etc/sgml/catalog is the "super catalog". It contains CATALOG pointers to all the centralized catalogs: -- sample contents of /etc/sgml/catalog -- CATALOG /etc/sgml/sgml-docbook.cat CATALOG /etc/sgml/xhtml.cat CATALOG /etc/sgml/mathml.cat One can use DELEGATE instead of CATALOG if this directive is known to be supported. It should not point to centralized catalogs that are merely symbolic links and therefore are already mentioned. The users should be able to define their own centralized catalogs and their own super catalog in their home directories: $HOME/.sgml-docbook.cat $HOME/.catalog The SGML applications are not supposed to use centralized catalogs, although their use is stronlgy encouraged: if other mechanisms allow one to locate the real catalogs, they can be used as well. However distribution packagers should always take care of feeding the right entries into the super catalog and the centralized catalogs. The interface for a script named "install-catalog" that does these maintenance tasks is described here: install-catalog --add|--remove <centralized_catalog> <ordinary_catalog> Example: install-catalog --add \ /etc/sgml/sgml-docbook-3.1 \ /usr/share/sgml/docbook/dsssl-stylesheets-1.54/catalog The other catalogs should be placed in subdirectories of /usr/share/sgml. They should all be named "catalog". They are the ones who do the real work of mapping the FPIs to file names (among other tasks). R004 - Open Catalog usage for DocBook ------------------------------------- This recomendation is merely a consequence of the preceeding recomendations. For a Jade- or Openjade-based distribution of DocBook, we suggest the following names. Again, other SGML or XML DTDs can be based on this structure. /etc/sgml/ sgml-docbook.cat xml-docbook.cat sgml-docbook-3.0.cat sgml-docbook-3.1.cat sgml-docbook-4.0.cat xml-docbook-4.0.cat /usr/share/sgml/sgml-iso-entities-8879.1986/catalog /usr/share/sgml/xml-iso-entities-8879.1986/catalog /usr/share/sgml/jade-1.2.1/catalog /usr/share/sgml/openjade-1.0/catalog /usr/share/sgml/docbook/sgml-dtd-3.0/catalog /usr/share/sgml/docbook/sgml-dtd-3.1/catalog /usr/share/sgml/docbook/sgml-dtd-4.0/catalog /usr/share/sgml/docbook/xsl-dtd-4.0/catalog /usr/share/sgml/docbook/dsssl-stylesheets-1.54/catalog /usr/share/sgml/docbook/xsl-stylesheets-1.12/catalog R005 - Configuration files -------------------------- Other configuration files may also reside in /etc/sgml, either DTD-specific or application-specific. Their name should end in ".conf" and they should follow ordinary rules for files residing in /etc as defined by LSB. The user should be able to redefine them in his/her home directory. Their syntax and purpose is not defined in this document. R006 - Iso-entities ------------------- The file names should be fixed to: ISOamsa.ent ISOamsb.ent ... The identifiers should be fixed to: "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" In the transitory period, symbolic links and duplicate declarations will be allowed as a means to preserve the compatibility with previous naming schemes. R007 - Packages --------------- C programs can get compiled with any version of a given compiler. SGML documents can't use any version of a given DTD. They need the corresponding DTD to reside on the same system, or at least to be reachable. The various versions of a given DTD in turn may imply certain versions of the style sheets. This leads to a unusual situation where the old DTDs and style sheets should not be replaced during a package update. We would like to make the solutions to achieve this aware to distribution packagers. They may choose to: - put the version number in the package name field (example: docbook-dtd-3.1-1.0.rpm) - not put the version number and use subpackages for each version sgml-base-doc-1.99.2/sgml_layout.sgml0000644000000000000000000001273012763406467014364 0ustar SGML Entity Management Manoj Srivastava srivasta@debian.org This document provides a guidelines for implementation dependent Entity management of SGML entities for Debian systems. This defines the mapping of External Public Identifiers to System Identifiers. (In other words, this document covers the use of /usr/lib/sgml, entity naming, and catalog files. Copyright ©1998 Manoj Srivastava

This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.

Introduction and Scope

This document was written by Manoj Srivastava srivasta@debian.org with contributions from Mark W. Eichin eichin@kitten.gen.ma.us and Adam P. Harris aph@debian.org. This document is part of the sgml-base package.

This guideline is intended to be intepreted as SGML sub-policy (not official policy). While this document does not carry the weight of official policy, it is sufficient basis for the submission of bugs against a package. This may change at a latter date.

Entity Management is generally left up to the implementation, and hence there are no extant Standards that cover this. However, lack of an established convention would prevent different segments of the SGML subsystem from co-operating with each other, hence it is important that a policy be established so that SGML package maintainers may depend on other parts of the system behaving consistently.

Proposed mapping of public identifiers to system identifiers

SGML can refer to an external file (really an entity) with an external identifier: this is a public identifier or a system identifier, or both.

A typical public identifier looks like PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" where ISO 8879-1986 is the owner, ENTITIES is the text class and Added Latin 1 is the text description, and EN is language.

A system identifier looks like SYSTEM "htmlplus.dtd" where htmlplus.dtd is a system-specific identifier.

To map external identifiers to file names, one should first try the system identifier, as a file name, and then search entity catalog files and then search the list of file names derived from the public identifier. The catalog format is according to SGML/Opens resolution on entity management. The catalog consists of a series of entries and comments. A comment is delimited by -- like in a markup declaration.

The fallback derivation of the file name is modelled after the sgmls environment variable SGML_PATH, and Emacs psgml mode's sgml-public-map variable. There does not seem to be any official standards (this is left to the implementation), so this standard is simply an abstraction of real-world practice of SGML tools, and shall now be the standard for Debian systems, since this is the convention currently followed by all applications currently in Debian.

Contiguous white space is compacted to a single space and replaced with an underscore (_); the characters / to % are also replaced with _. The text class is down-cased. The language specifier (i.e., //EN) and anything following it should be removed.

Location of miscellaneous files

There are a number of other files, though not entities referenced by Document instances, are still required by the SGML subsytem to parse or validate the document. These files are also covered by this document.

Declaration Files: Any declaration file should be put in /usr/lib/sgml/declaration

Notations: These files go in /usr/lib/sgml/notation.

Examples

A few public and system identifiers pairings are shown below. PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" /usr/lib/sgml/ISO_8879-1986/entities/Added_Latin_1 "ISO 8879-1986//ENTITIES Added Math Symbols: Arrow Relations//EN" /usr/lib/sgml/ISO_8879-1986/entities/Added_Math_Symbols:_Arrow_Relations "-//IETF//DTD HTML Level 3//EN//3.0" /usr/lib/sgml/IETF/dtd/HTML_Level_3.0 "-//IETF//DTD HTML Strict Level 3//EN" /usr/lib/sgml/IETF/dtd/HTML_Strict_Level_3 "-//USA-DOD//DTD Table Model 951010//EN" /usr/lib/sgml/USA-DOD/dtd/Table_Model_951010

The first four actually exist in Debian.

sgml-base-doc-1.99.2/POLICY0000644000000000000000000000570712763406467012071 0ustar Debian SGML/XML Policy (draft) ============================== Currently, the policy is spread over several documents: - RECOMMENDATIONS.lsb - EXPLANATIONS.lsb - RECOMMENDATIONS.fsh - "SGML Entity Management" - this file In the near future this will all be integrated into a single official document, with the exception of RECOMMENDATIONS.fsh which will be a part of FHS v2.2. Besides the directory structure described in RECOMMENDATIONS.lsb, we will also support a non-versioned directory structure as proposed by Mark Johnson (excerpt from his message on debian-sgml): -- Directory Structure Comment: --------------------- On the proposed directory structure -- grouped by classes of dtds rather than file function: -Current dir structure: /usr/[share or lib]/sgml/ dtd/ stylesheet/ entities/ -Proposed: /usr/share/sgml/docbook/ sgml-dtd-3.1/ sgml-dtd-4.0/ xml-dtd-4.0/ (the DocBook DTD) dsssl-stylesheets-1.54/ xsl-stylesheets-1.12/ Wouldn't a hybrid of the two make much more sense? Something like: /usr/share/sgml/docbook/ dtd/ stylesheet/ entities/ The proposed structure looks unnecessarily messy, and harder to maintain. -- Package dependencies -------------------- All SGML and XML packages that provide a DTD or entity description file have to depend on the "sgml-base" package. This package implements the necessary infrastructure as described in the files RECOMMENDATIONS.lsb and RECOMMENDATIONS.fsh. Please don't modify the super catalog and the centralized catalogs directly in the postinst/prerm scripts of your package. Please use update-catalog(8) for that purpose. Example ------- Here is a simple example: Consider the package "foo" which provides the SGML DTD foo.dtd and an entity description file "foo-general". The package installs the following files: /usr/share/sgml/foo/sgml-dtd-/dtd/foo.dtd /usr/share/sgml/foo/sgml-dtd-/entities/foo-general /usr/share/sgml/foo/sgml-dtd-/catalog The catalog file can look like this: DOCTYPE foodoc foo/sgml-dtd-/dtd/foo.dtd ENTITY %foo-general foo/sgml-dtd-/entities/foo-general That's the postinst script: #!/bin/sh set -e if [ "$1" = configure ] then CENCAT=/etc/sgml/foo-.cat ORDCAT=/usr/share/sgml/foo-/catalog update-catalog --add $CENCAT $ORDCAT update-catalog --add --super $CENCAT fi #DEBHELPER exit 0 and the prerm script: #!/bin/sh set -e if [ "$1" = remove ] then CENCAT=/etc/sgml/foo-.cat ORDCAT=/usr/share/sgml/foo-/catalog update-catalog --remove --super $CENCAT update-catalog --remove $CENCAT $ORDCAT fi #DEBHELPER exit 0 Please check the update-catalog(8) manpage for details. Feedback -------- Please send me an email for bugs/suggestions/critics on this policy. February 2001 Ardo van Rangelrooij sgml-base-doc-1.99.2/RECOMMENDATIONS.fhs0000644000000000000000000000523012763406467014067 0ustar File system recommendations for SGML and XML layout --------------------------------------------------- Introduction ------------ In a normalisation effort, about thirty people, including packagers of some Linux distributions, and developers of SGML related tools such as the SGML-Tools and DocBook Tools project, discussed informally and agreed on a series of recommendations that will be submitted as a draft to the Linux Standard Base project. A reference implementation will also be done as part of the DocBook-tools project. This document addresses the FHS part of the project. This document makes several references to "catalogs": these files represent the dorsal spine of a SGML or XML system. They are mainly used to map things (that are called "entities" in SGML or XML terminology) into real file names. A catalog can reference other catalogs through pointer directives (CATALOG, DELEGATE). For more information, see the Open Catalogs standard at http://www.oasis-open.org. /etc/sgml/ ---------- In /etc/sgml one can find configuration files that describe the installed components of a SGML or XML system. Files found there include: *.conf: generic configuration files *.cat: DTD-specific centralized catalogs catalog: the super catalog The generic configuration files define high-level parameters of the SGML or XML system. The "centralized catalogs" are catalogs that reference through pointers all the other catalogs that are needed to use a given DTD. The referenced files include the DTD's catalog, style sheets catalogs, character entities sets catalogs, etc. All the files that are referenced reside somewhere under /usr/share/sgml. The "super catalog" references through pointers all the centralized catalogs. Unlike the centralized catalogs, it does not guarantee the absence of definition conflicts between referenced catalogs. At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /etc/xml. /usr/share/sgml/ ---------------- In /usr/share/sgml reside architecture-independent files used by SGML or XML applications: ordinary catalogs (not the centralized ones), DTDs, entities, style sheets, and other declarative files, if any. It is organized at top-level into DTD-specific subdirectories, when applicable: docbook/ tei/ html/ mathml/ ... Other files that are not specific to a given DTD may reside in their own directory. When we say "specific to a DTD", it does not mean that those files describe a DTD, but only that they are to be used with this DTD. At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /usr/share/xml. sgml-base-doc-1.99.2/README0000644000000000000000000000110212763406467012010 0ustar IMPORTANT NOTE -------------- This version of sgml-base starts the transition of /usr/lib/sgml to /usr/share/sgml. The documentation is not yet integrated into one single nice document with good examples and guidelines. This will definitely change in the near future. Also the support in the form of tools is still in its infancy. This version mainly only moves the catalogs into place and introduces a tool called update-catalog. Feedback -------- Please send me an email for bugs/suggestions/critics on this note. February 2001 Ardo van Rangelrooij sgml-base-doc-1.99.2/debian/0000755000000000000000000000000012763406467012360 5ustar sgml-base-doc-1.99.2/debian/sgml-base-doc.doc-base0000644000000000000000000000101112763406467016365 0ustar Document: sgml-doc-base Title: SGML Entity Management Author: Manoj Srivastava Abstract: This document provides guidelines for implementation dependent Entity management of SGML entities for Debian systems. Section: Debian Format: HTML Index: /usr/share/doc/sgml-base-doc/sgml_layout.html/index.html Files: /usr/share/doc/sgml-base-doc/sgml_layout.html/*.html Format: PDF Files: /usr/share/doc/sgml-base-doc/sgml_layout.pdf.gz Format: text Files: /usr/share/doc/sgml-base-doc/sgml_layout.txt.gz sgml-base-doc-1.99.2/debian/sgml-base-doc.docs0000644000000000000000000000017012763406467015645 0ustar POLICY README sgml_layout.html sgml_layout.pdf sgml_layout.txt EXPLANATIONS.lsb RECOMMENDATIONS.lsb RECOMMENDATIONS.fhs sgml-base-doc-1.99.2/debian/rules0000755000000000000000000000116412763406467013442 0ustar #!/usr/bin/make -f #export DH_VERBOSE=1 PACKAGE = sgml-base-doc PKG_DOCS = sgml_layout.html sgml_layout.pdf sgml_layout.txt .SUFFIXES: .html .pdf .sgml .txt .sgml.html: debiandoc2html $< .sgml.pdf: debiandoc2latexpdf -p letter $^ .sgml.txt: debiandoc2text $^ check: check-stamp check-stamp: sgml_layout.sgml dh_testdir onsgmls -wall -E20 -gues $< touch $@ build: $(if $(findstring nocheck,$(DEB_BUILD_OPTIONS)),,check) $(PKG_DOCS) binary binary-arch binary-indep clean install: dh $@ override_dh_clean: $(RM) -r $(PKG_DOCS) sgml_layout.tpt dh_clean .PHONY: binary binary-arch binary-indep check clean install sgml-base-doc-1.99.2/debian/copyright0000644000000000000000000000150212763406467014311 0ustar This is the Debian package of the documentation for sgml-base. It was assembled by Ardo van Rangelrooij . It is currently maintained by Ardo van Rangelrooij and the Debian XML/SGML Group . ---------------------------------------------------------------------- Copyright of the sgml-base manual: Copyright (c) 1998 Manoj Srivastava This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. ---------------------------------------------------------------------- On a Debian system a copy of the GNU General Public License can be found in the file '/usr/share/common-licenses/GPL'. sgml-base-doc-1.99.2/debian/README.Debian0000644000000000000000000000071512763406467014424 0ustar sgml-base-doc for Debian ======================== The source files for the documentation in this package can be obtained as follows: 1. Include a "deb-src" line in the "/etc/sources.list", e.g. deb-src http://ftp.us.debian.org/debian/ unstable main For more information on this see the manual page sources.list(5). 2. Download the source withthe following command: apt-get source sgml-base-doc -- Ardo van Rangelrooij sgml-base-doc-1.99.2/debian/control0000644000000000000000000000151412763406467013764 0ustar Source: sgml-base-doc Section: doc Priority: optional Maintainer: Debian QA Group Standards-Version: 3.8.3 Build-Depends: debhelper (>> 7.0.50~) Build-Depends-Indep: debiandoc-sgml, ghostscript, libpaperg, opensp, texlive, texlive-latex-extra Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/sgml-base-doc/ Vcs-Svn: svn://svn.debian.org/svn/debian-xml-sgml/packages/sgml-base-doc/trunk/ Homepage: http://debian-xml-sgml.alioth.debian.org Package: sgml-base-doc Architecture: all Conflicts: sgml-base (<= 1.12) Replaces: sgml-base (<= 1.12) Depends: ${misc:Depends} Suggests: sgml-base (>= 1.13) Description: Documentation for sgml-base This package contains the documentation for sgml-base, providing the SGML infrastructure directories and catalog file support, in HTML, PDF and plain text format. sgml-base-doc-1.99.2/debian/changelog0000644000000000000000000000535712763406467014244 0ustar sgml-base-doc (1.99.2) unstable; urgency=medium * QA upload. * Changed build dependency on sp to opensp. -- Neil Roeth Mon, 05 Sep 2016 20:26:31 -0400 sgml-base-doc (1.99.1) unstable; urgency=low * Upload to unstable to fix FTBFS. * debian/control (Standards-Version): Bumped to 3.8.3. (Build-Depends): Increased for dh level 7. (Depends): Fixed debhelper-but-no-misc-depends. * debian/compat: Bumped to 7. * debian/rules: Adjusted for dh level 7. -- Daniel Leidert (dale) Fri, 22 Jan 2010 01:18:03 +0100 sgml-base-doc (1.99.0) experimental; urgency=low * Makefile: Dropped build system. debian/rules and debhelper are enough. * debian/compat: Increased compatibility level to 5. * debian/control: Added Vcs*, Homepage and DM-Upload-Allowed fields. (Uploaders): Added myself. (Build-Depends-Indep): Moved debhelper to Build-Depends. Replaced tetex* packages by texlive packages (closes: #562307). (Standards-Version): Bumped to 3.8.2. * debian/rules: Rewritten in parts. Now contains all stuff from the Makefile. Added a check target. * debian/sgml-base-doc.doc-base (Document): Fixed. Thanks to lintian. * debian/sgml-base-doc.README.Debian: Renamed to debian/README.Debian. -- Daniel Leidert (dale) Sun, 12 Jul 2009 16:21:16 +0200 sgml-base-doc (1.16) unstable; urgency=low * debian/control: upgraded to Debian Policy 3.6.1 (no changes) * debian/control: changed 'Maintainer' to 'Debian XML/SGML Group ' and added current maintainer to 'Uploaders' -- Ardo van Rangelrooij Thu, 22 Apr 2004 07:54:27 -0500 sgml-base-doc (1.15) unstable; urgency=low * Removed document sources from binary package and indicated in README.Debian how to get the source package * debian/rules: moved debhelper compatibility level setting to 'debian/compat' per latest debhelper best practices * debian/control: changed build dependency on 'debhelper' to '(>= 4.1)' * debian/control: upgraded to Debian Policy 3.6.0 (no changes) -- Ardo van Rangelrooij Tue, 12 Aug 2003 21:02:30 -0500 sgml-base-doc (1.14) unstable; urgency=low * debian/rules: upgraded to debhelper v4 * debian/control: changed build dependency on debhelper accordingly * debian/rules: migrated from 'dh_movefiles' to 'dh_install' * debian/rules: split off 'install' target from 'binary-indep' target * debian/copyright: added pointer to license -- Ardo van Rangelrooij Sat, 10 Aug 2002 13:58:20 -0500 sgml-base-doc (1.13) unstable; urgency=low * Initial release as a separate package -- Ardo van Rangelrooij Sun, 17 Feb 2002 13:34:28 -0600 sgml-base-doc-1.99.2/debian/compat0000644000000000000000000000000212763406467013556 0ustar 7 sgml-base-doc-1.99.2/debian/TODO0000644000000000000000000000202412763406467013046 0ustar ------------------------------------------------------------------------------ To do list for sgml-base-doc ------------------------------------------------------------------------------ BUGS: ------------------------------------------------------------------------------ Number Description ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ WISHLIST: ------------------------------------------------------------------------------ Number Description ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ VARIOUS: ------------------------------------------------------------------------------ Description ------------------------------------------------------------------------------ * rewrite to reflect current * clean out what's not needed anymore ------------------------------------------------------------------------------ sgml-base-doc-1.99.2/.svn/0000755000000000000000000000000012763406467012022 5ustar sgml-base-doc-1.99.2/.svn/entries0000644000000000000000000000000312763406467013407 0ustar 12 sgml-base-doc-1.99.2/.svn/wc.db-journal0000644000000000000000000000000012763406467014400 0ustar sgml-base-doc-1.99.2/.svn/wc.db0000644000000000000000000036000012763406467012741 0ustar SQLite format 3@ 44-ýqûû ®®P]Usvn://svn.debian.org/svn/debian-xml-sgml43dd4653-54d6-0310-8d79-ce393162d6a7 ÔÔ+] svn://svn.debian.org/svn/debian-xml-sgml ÖñæÖ!WORK_QUEUE  WCROOT ! REPOSITORY ØØ'U 43dd4653-54d6-0310-8d79-ce393162d6a7 ÔÔ+] svn://svn.debian.org/svn/debian-xml-sgml ûû üü üü  €¢Dæˆ* Ì o  ´ V ø š < Þ €\i Y$sha1$f3617f39c2fed6b85abbeeb8daea27851db7d0ee(x$md5 $8ad79336274bfbf25101594acccee4c2\i Y$sha1$e29f288af9c780f4b00ba2c802a027deaac996f8Í$md5 $713991484a4c3ae870ede2a2fceee3fb\ i Y$sha1$7d96cdbf057b24cacc8af388798e71ddf98cb4d9s$md5 $78adcbbfca9fb4825699f325bd33d822\ i Y$sha1$ba68a4e0e4550c7d800776258c1930641212d7f7 $md5 $c2328922ee2da3b3cbb7ae7519bea1ea\ i Y$sha1$3656f81b827a0147f481270b28024c1951fcd7bfB$md5 $d1a8c79fab83766fb980e65c90781a7b\ i Y$sha1$f8efd3439db82e50c9e5432331fe2ba43dc9e15d Ø$md5 $930a39c19b3d14ad1ef52e41278e8943\ i Y$sha1$044de9580c8a46547295b5dbec1ce4b9c49525a9$md5 $594b2d923d14b736a704f5c5928160c1[i Y$sha1$6b389ab8a38104da46a704642e6fdf714fcc18cfx$md5 $be6251663cbf6361fff61b6f91463205[i Y$sha1$d3964f9dad9f60363c81b688324d95b4ec7c8038$md5 $84bc3da1b3e33a18e8d5e1bdd7a18d7a\i Y$sha1$7448eaf4b675c022bc7d512cee457d7bbf59bc8bÞ$md5 $13a22542936b934db2af6ce8f7dfadd9\i Y$sha1$062f3e7ca0d654db5c85d736d083e1811c54a77fØ$md5 $5cce755c42ad561b4936343e0c3d0e93\i Y$sha1$8ce0a49f6993a66576a4b766a026487424e1b2f2 Ç$md5 $75c5aaa1a1bc5dee4b6dcb5dd9aaafdc\i Y$sha1$6f51150b8bb3cf4a19d149f26f8b95bcac2d972dB$md5 $ef567d21b42f7b0a8b1c6517fe517e20\i Y$sha1$7587289ab2c562061e3c52b48d2766a42774f7b3($md5 $0c8355162eda05fb1a683861ead8beac\i Y$sha1$a8f1a5ea07a1e93076c04057534d45726411e417 ˜$md5 $46fa028574a8bbb1278afcdfa53bf898  6 ÐihÏ› j5Î œ 7 2i$sha1$f3617f39c2fed6b85abbeeb8daea27851db7d0ee2i$sha1$e29f288af9c780f4b00ba2c802a027deaac996f82i$sha1$7d96cdbf057b24cacc8af388798e71ddf98cb4d9 2i$sha1$ba68a4e0e4550c7d800776258c1930641212d7f7 2i$sha1$3656f81b827a0147f481270b28024c1951fcd7bf 2i$sha1$f8efd3439db82e50c9e5432331fe2ba43dc9e15d 2i$sha1$044de9580c8a46547295b5dbec1ce4b9c49525a9 2i$sha1$6b389ab8a38104da46a704642e6fdf714fcc18cf2i$sha1$d3964f9dad9f60363c81b688324d95b4ec7c80382i$sha1$7448eaf4b675c022bc7d512cee457d7bbf59bc8b2i$sha1$062f3e7ca0d654db5c85d736d083e1811c54a77f2i$sha1$8ce0a49f6993a66576a4b766a026487424e1b2f22i$sha1$6f51150b8bb3cf4a19d149f26f8b95bcac2d972d2i$sha1$7587289ab2c562061e3c52b48d2766a42774f7b31i $sha1$a8f1a5ea07a1e93076c04057534d45726411e417  |«ÿÖ~* §U ÒÔ |S© ý(€*Y$md5 $8ad79336274bfbf25101594acccee4c2*Y$md5 $713991484a4c3ae870ede2a2fceee3fb*Y$md5 $78adcbbfca9fb4825699f325bd33d822 *Y$md5 $c2328922ee2da3b3cbb7ae7519bea1ea *Y$md5 $d1a8c79fab83766fb980e65c90781a7b *Y$md5 $930a39c19b3d14ad1ef52e41278e8943 *Y$md5 $594b2d923d14b736a704f5c5928160c1 *Y$md5 $be6251663cbf6361fff61b6f91463205*Y$md5 $84bc3da1b3e33a18e8d5e1bdd7a18d7a*Y$md5 $13a22542936b934db2af6ce8f7dfadd9*Y$md5 $5cce755c42ad561b4936343e0c3d0e93*Y$md5 $75c5aaa1a1bc5dee4b6dcb5dd9aaafdc*Y$md5 $ef567d21b42f7b0a8b1c6517fe517e20*Y$md5 $0c8355162eda05fb1a683861ead8beac)Y $md5 $46fa028574a8bbb1278afcdfa53bf898      Ô š š š š š š š š š š š š š6Õ©}V!øÎ¢€^ ù û »q÷U ³ ý E à  U™Âý)-»Ä3 - gi)EXPLANATIONS.lsbpackages/sgml-base-doc/trunk/EXPLANATIONS.lsbânormalfile()$sha1$f3617f39c2fed6b85abbeeb8daea27851db7d0ee{UèyZúdleidert-guest(x;̹ÂJ9 3 mi)RECOMMENDATIONS.fhspackages/sgml-base-doc/trunk/RECOMMENDATIONS.fhsânormalfile()$sha1$a8f1a5ea07a1e93076c04057534d45726411e417{UèyZúdleidert-guest ˜;̹Â:bn  S)debianpackages/sgml-base-doc/trunk/debianânormaldir()infinity‰}¶6x–Çdleidert-guest³'c  E)packages/sgml-base-doc/trunkânormaldir()infinity‰}¶6x–Çdleidert-guest()Q 5 o0i)debian/README.Debiandebianpackages/sgml-base-doc/trunk/debian/README.Debianânormalfile(svn:mergeinfo 0 )$sha1$e29f288af9c780f4b00ba2c802a027deaac996f8‰}¶6x–Çdleidert-guestÍ;̹Â:bB % _2i)debian/rulesdebianpackages/sgml-base-doc/trunk/debian/rulesânormalfile(svn:executable 0 )$sha1$7d96cdbf057b24cacc8af388798e71ddf98cb4d9‰}¶6x–Çdleidert-guests;̹Â:bT G i)debian/sgml-base-doc.doc-basedebianpackages/sgml-base-doc/trunk/debian/sgml-base-doc.doc-baseânormalfile()$sha1$ba68a4e0e4550c7d800776258c1930641212d7f7‰}¶6x–Çdleidert-guest ;̹Â:b9  - gi)debian/copyrightdebianpackages/sgml-base-doc/trunk/debian/copyrightânormalfile()$sha1$3656f81b827a0147f481270b28024c1951fcd7bf‰}¶6x–Çdleidert-guestB;̹Â:b9  - gi)debian/changelogdebianpackages/sgml-base-doc/trunk/debian/changelogânormalfile()$sha1$f8efd3439db82e50c9e5432331fe2ba43dc9e15d‰}¶6x–Çdleidert-guest Ø;̹Â:b/  # ]i)debian/TODOdebianpackages/sgml-base-doc/trunk/debian/TODOânormalfile()$sha1$044de9580c8a46547295b5dbec1ce4b9c49525a9{UèyZúdleidert-guest;̹Â:bJ  ? yi)debian/sgml-base-doc.docsdebianpackages/sgml-base-doc/trunk/debian/sgml-base-doc.docsânormalfile()$sha1$6b389ab8a38104da46a704642e6fdf714fcc18cf{UèyZúdleidert-guestx;̹Â:b2  ' ai)debian/compatdebianpackages/sgml-base-doc/trunk/debian/compatânormalfile()$sha1$d3964f9dad9f60363c81b688324d95b4ec7c8038‰}¶6x–Çdleidert-guest;̹Â:b5 ) ci)debian/controldebianpackages/sgml-base-doc/trunk/debian/controlânormalfile()$sha1$7448eaf4b675c022bc7d512cee457d7bbf59bc8b‰}¶6x–Çdleidert-guestÞ;̹Â:b3 - gi)sgml_layout.sgmlpackages/sgml-base-doc/trunk/sgml_layout.sgmlânormalfile()$sha1$062f3e7ca0d654db5c85d736d083e1811c54a77f{UèyZúdleidert-guestØ;̹Â:b  Si)POLICYpackages/sgml-base-doc/trunk/POLICYânormalfile()$sha1$8ce0a49f6993a66576a4b766a026487424e1b2f2{UèyZúdleidert-guest Ç;̹Â:b  Si)READMEpackages/sgml-base-doc/trunk/READMEânormalfile()$sha1$6f51150b8bb3cf4a19d149f26f8b95bcac2d972d{UèyZúdleidert-guestB;̹Â:b9 3 mi)RECOMMENDATIONS.lsbpackages/sgml-base-doc/trunk/RECOMMENDATIONS.lsbânormalfile()$sha1$7587289ab2c562061e3c52b48d2766a42774f7b3{UèyZúdleidert-guest(;̹Â:bM ú–¬¹àƈ­-_sÿÈÛ?•  -EXPLANATIONS.lsb 5debian/README.Debian %debian/rules# Gdebian/sgml-base-doc.doc-base -debian/copyright  -debian/changelog  #debian/TODO  ?debian/sgml-base-doc.docs  'debian/compat  )debian/control  debian -sgml_layout.sgml  POLICY  README 3RECOMMENDATIONS.lsb 3RECOMMENDATIONS.fhs ùGGO§µÞÃg ìJeΉ£#  -EXPLANATIONS.lsb! 5debiandebian/README.Debian %debiandebian/rules* Gdebiandebian/sgml-base-doc.doc-base -debiandebian/copyright  -debiandebian/changelog  #debiandebian/TODO & ?debiandebian/sgml-base-doc.docs  'debiandebian/compat  )debiandebian/control  debian -sgml_layout.sgml  POLICY  README 3RECOMMENDATIONS.lsb 3RECOMMENDATIONS.fhs úƒóìåÞ×É»´­¦Ÿ˜‘Њƒ                       ‚&ÃÔŽH ¡ @ ?  å o ®¸‚ïÔìÄ@ÙÏj–“‚ ƒwtableLOCKLOCKCREATE TABLE LOCK ( repos_id INTEGER NOT NULL REFERENCES REPOSITORY (id), repos_relpath TEXT NOT NULL, lock_token TEXT NOT NULL, lock_owner TEXT, lock_comment TEXT, lock_date INTEGER, PRIMARY KEY (repos_id, repos_relpath) )ø)4+#‚'indexI_ACTUAL_PARENTACTUAL_NODECREATE UNIQUE INDEX I_ACTUAL_PARENT ON ACTUAL_NODE (wc_id, parent_relpath, local_relpath)„< ##ˆ?tableACTUAL_NODEACTUAL_NODE CREATE TABLE ACTUAL_NODE ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, parent_relpath TEXT, properties BLOB, conflict_old TEXT, conflict_new TEXT, conflict_working TEXT, prop_reject TEXT, changelist TEXT, text_mod TEXT, tree_conflict_data TEXT, conflict_data BLOB, older_checksum TEXT REFERENCES PRISTINE (checksum), left_checksum TEXT REFERENCES PRISTINE (checksum), right_checksum TEXT REFERENCES PRISTINE (checksum), PRIMARY KEY (wc_id, local_relpath) )5 I#indexsqlite_autoindex_ACTUAL_NODE_1ACTUAL_NODEX )yindexI_PRISTINE_MD5PRISTINE CREATE INDEX I_PRISTINE_MD5 ON PRISTINE (md5_checksum)M ‚mtablePRISTINEPRISTINE CREATE TABLE PRISTINE ( checksum TEXT NOT NULL PRIMARY KEY, compression INTEGER, size INTEGER NOT NULL, refcount INTEGER NOT NULL, md5_checksum TEXT NOT NULL )/ Cindexsqlite_autoindex_PRISTINE_1PRISTINE _+indexI_LOCAL_ABSPATHWCROOT CREATE UNIQUE INDEX I_LOCAL_ABSPATH ON WCROOT (local_abspath)xKtableWCROOTWCROOTCREATE TABLE WCROOT ( id INTEGER PRIMARY KEY AUTOINCREMENT, local_abspath TEXT UNIQUE )+?indexsqlite_autoindex_WCROOT_1WCROOTD!]indexI_ROOTREPOSITORYCREATE INDEX I_ROOT ON REPOSITORY (root)D!]indexI_UUIDREPOSITORYCREATE INDEX I_UUID ON REPOSITORY (uuid)P++Ytablesqlite_sequencesqlite_sequenceCREATE TABLE sqlite_sequence(name,seq)!!tableREPOSITORYREPOSITORYCREATE TABLE REPOSITORY ( id INTEGER PRIMARY KEY AUTOINCREMENT, root TEXT UNIQUE NOT NULL, uuid TEXT NOT NULL )3G!indexsqlite_autoindex_REPOSITORY_1REPOSITORY ´e×XsD l A • . $¿å ¼¨²eK %%[tablesqlite_stat1sqlite_stat1CREATE TABLE sqlite_stat1(tbl,idx,stat)s3ƒ!indexI_EXTERNALS_DEFINEDEXTERNALSCREATE UNIQUE INDEX I_EXTERNALS_DEFINED ON EXTERNALS (wc_id, def_local_relpath, local_relpath)ƒV†{tableEXTERNALSEXTERNALSCREATE TABLE EXTERNALS ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, parent_relpath TEXT NOT NULL, repos_id INTEGER NOT NULL REFERENCES REPOSITORY (id), presence TEXT NOT NULL, kind TEXT NOT NULL, def_local_relpath TEXT NOT NULL, def_repos_relpath TEXT NOT NULL, def_operational_revision TEXT, def_revision TEXT, PRIMARY KEY (wc_id, local_relpath) )1Eindexsqlite_autoindex_EXTERNALS_1EXTERNALS‚LG„Etriggernodes_update_checksum_triggernodesCREATE TRIGGER nodes_update_checksum_trigger AFTER UPDATE OF checksum ON nodes WHEN NEW.checksum IS NOT OLD.checksum BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; ENDW5‚mtriggernodes_delete_triggernodesCREATE TRIGGER nodes_delete_trigger AFTER DELETE ON nodes WHEN OLD.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; ENDW5‚mtriggernodes_insert_triggernodesCREATE TRIGGER nodes_insert_trigger AFTER INSERT ON nodes WHEN NEW.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; ENDc!!viewNODES_BASENODES_BASECREATE VIEW NODES_BASE AS SELECT * FROM nodes WHERE op_depth = 0‚''ƒQviewNODES_CURRENTNODES_CURRENTCREATE VIEW NODES_CURRENT AS SELECT * FROM nodes AS n WHERE op_depth = (SELECT MAX(op_depth) FROM nodes AS n2 WHERE n2.wc_id = n.wc_id AND n2.local_relpath = n.local_relpath)e'indexI_NODES_MOVEDNODESCREATE UNIQUE INDEX I_NODES_MOVED ON NODES (wc_id, moved_to, op_depth)))‚indexI_NODES_PARENTNODESCREATE UNIQUE INDEX I_NODES_PARENT ON NODES (wc_id, parent_relpath, local_relpath, op_depth))=indexsqlite_autoindex_NODES_1NODES…U‹ tableNODESNODESCREATE TABLE NODES ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, op_depth INTEGER NOT NULL, parent_relpath TEXT, repos_id INTEGER REFERENCES REPOSITORY (id), repos_path TEXT, revision INTEGER, presence TEXT NOT NULL, moved_here INTEGER, moved_to TEXT, kind TEXT NOT NULL, properties BLOB, depth TEXT, checksum TEXT REFERENCES PRISTINE (checksum), symlink_target TEXT, changed_revision INTEGER, changed_date INTEGER, changed_author TEXT, translated_size INTEGER, last_mod_time INTEGER, dav_cache BLOB, file_external INTEGER, inherited_props BLOB, PRIMARY KEY (wc_id, local_relpath, op_depth) )-Aindexsqlite_autoindex_WC_LOCK_1WC_LOCKbƒtableWC_LOCKWC_LOCKCREATE TABLE WC_LOCK ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_dir_relpath TEXT NOT NULL, locked_levels INTEGER NOT NULL DEFAULT -1, PRIMARY KEY (wc_id, local_dir_relpath) )}!!EtableWORK_QUEUEWORK_QUEUECREATE TABLE WORK_QUEUE ( id INTEGER PRIMARY KEY AUTOINCREMENT, work BLOB NOT NULL )';indexsqlite_autoindex_LOCK_1LOCK    _Ч‚HðÀŒ_+ 3#EXTERNALSI_EXTERNALS_DEFINED100 100 3 12EEXTERNALSsqlite_autoindex_EXTERNALS_1100 100 1.AWC_LOCKsqlite_autoindex_WC_LOCK_1100 100 1(;LOCKsqlite_autoindex_LOCK_1100 100 1,#+)ACTUAL_NODEI_ACTUAL_PARENT8000 8000 10 18#I#ACTUAL_NODEsqlite_autoindex_ACTUAL_NODE_18000 8000 1#''NODESI_NODES_MOVED8000 8000 1 1')-NODESI_NODES_PARENT8000 8000 10 2 1.='NODESsqlite_autoindex_NODES_18000 8000 2 1sgml-base-doc-1.99.2/.svn/tmp/0000755000000000000000000000000012763406467012622 5ustar sgml-base-doc-1.99.2/.svn/pristine/0000755000000000000000000000000012763406467013657 5ustar sgml-base-doc-1.99.2/.svn/pristine/f3/0000755000000000000000000000000012763406467014167 5ustar sgml-base-doc-1.99.2/.svn/pristine/f3/f3617f39c2fed6b85abbeeb8daea27851db7d0ee.svn-base0000644000000000000000000002417012763406467024022 0ustar Explanantions of the recommendations to LSB ------------------------------------------- Introduction ------------ This document explains the choices that have been made for the recommendations to LSB about DocBook. This is presented in a separate document to leave the draft concentrate only on the "what?" and not on the "why?" There are hundreds of man-hours behind those recommendations. They really costed blood, sweat and tears. Each line was discussed many times and the global architecture changed quite often. We really tried to hear what everyone add to say. So we would like to encourage LSB in being very careful if they want to modify them. The general philosophy was to keep the "historical" choices everywhere it had no consequences, and the "best" technical choice wherever it was interesting. We have attempted to design a very simple but also powerful architecture, in full respect of the FHS (File system Hierarchy Standard). Another general principal of design was to think to the user, not to the theory. There were many models that would have been much more intellectually satisfactory - but they were all too complex for everyday's use. Definitions ----------- Why those definitions? Because we realized we were speaking about different things with the same words. An example is "SGML application": it can both refer to a specific DTD, or to a computer program meant to process some SGML or XML document, both definitions being perfectly correct. To avoid any potential confusion, we just chose the one we needed. Some definitions like "helper", "backend" and "frontend" are not even necessary to read the rest of the document. We left them because we needed them to provide a reference implementation. R001 - SGML Directory layout ---------------------------- Some existing projects were putting files in /usr/lib/sgml, some other in /usr/local/share/sgml. Those files are not libraries nor local to a system, so we chose /usr/share/sgml. Some projects used to put centralized catalogs at the same place as the other catalogs. Since they can be seen as system configuration files, it was locgical to centralize them in /etc. One very hard question was: should we separe sgml from xml? The relationship between one and the other is very strong, so we chose to keep them at the same place in the directory tree. This allows, for example, to have all docbook stuff, both sgml and xml, at the very same place, which is obviously practical. While /usr/share/sgml does not explicitely reflect this, we found that it was still better than /usr/share/markup (what about TeX then?), than /usr/share/ml or than other proposals. Why having fixed file paths while you could have got them from some configuration variables, autoconf mechanisms, etc? First because it's simpler: we wanted a very strong standard, given that the tools may still use such configuration variables or autoconf mechanisms to adapt to non-LSB platforms. We considered that a standard that does not specify enough is somehow encouraging the most bizarre variations. We chose a dtd-and-package-oriented architecture, instead of a file-type-oriented structure. This was probably the most controversial issue. The "natural" proposal for SGML and XML specialists is to have the FPIs map almost letter-per-letter in the directory names. However, this approach does not take profit of the catalogs mechanism that allow to map FPIs into file paths. A file-type-oriented architecture would have lead things like: /usr/share/sgml/USA-DOD/DTD_Table_Model_951010/EN/ /usr/share/sgml/OASIS/DTD_DocBook_V3.1/EN/ /usr/share/sgml/OASIS/ELEMENTS_DocBook_Information_Pool_V3.1/EN/ /usr/share/sgml/OASIS/ELEMENTS_DocBook_Document_Hierarchy_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Additional_General_Entities_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Notations_V3.1/EN/ /usr/share/sgml/OASIS/ENTITIES_DocBook_Character_Entities_V3.1/EN/ or something more far away from the FPIs like: /usr/share/sgml/sgml-dtd/hal/docbook/2.4/ /usr/share/sgml/sgml-dtd/davenport/docbook/3.0/ /usr/share/sgml/sgml-dtd/davenport/docbook/3.0/ /usr/share/sgml/sgml-dtd/oasis/docbook/3.1/ /usr/share/sgml/xml-dtd/oasis/docbook/4.0/ /usr/share/sgml/dssl-stylesheets/nwalsh/docbook/3.1/ /usr/share/sgml/xsl-stylesheets/nwalsh/docbook/4.0/ /usr/share/sgml/sgml-dtd/ietf/html/2.0/ /usr/share/sgml/sgml-dtd/w3c/html/3.2/ but in all the case, the files would have been spread according to their file types in distant directories. We would probably have had entities somewhere, stylesheets somewhere else, dtds in a third place, and sgml declarations in a fourth place. This would certainly have broke some relative paths, and required more packaging work. The user does not think in terms of file types, whereas SGML specialists do. The user only thinks "I want to do some MathML" or "I want to do some XHTML" or "I want to do some TEI". This is why the basic unit is the DTD. This DTD-centered approach does not mean that first level directories are for DTDs. It just means that they hold everything related to a given DTD: stylesheets, enterprise-wide customizations, etc... R002 - DocBook Directory layout ------------------------------- Maybe the document seems confused because it mixes recommendantions for SGML and XML with recommendations for DocBook. It would somehow have been good to separate it into two documents. On the other hand, this allowed to think in very practical terms. There is only one lower level of directories. The directory names are vaguely defined as holding one "package". One advantage is that the relation to any RPM or DEB package is very close. The other advantage is that we have a very flat tree, thus easing both hacking, packaging and maintenance by system administrators. The lower level directories are version-numbered. This unusual naming scheme is intended to permit documents that are written using several versions of the same DTD to coexist on the same system. R003 - Open Catalog usage for SGML ---------------------------------- Why focusing so much on catalogs in these recommendations? Because they are the key to your directory structure and give a strong working infrastructure that every SGML or XML tool can count on. Open catalogs have very often been resented because they lead to problems like conflicting SGMLDECLs. However, those problems do not appear if you use them carefully. One of the keys is to avoid putting everything in the same bag, and to have centralized catalogs that are specific to a given DTD. The fact that they are DTD-specific has a number of advantages: - avoid SGMLDECL conflicts without assuming DTDDECL or DELEGATE support, which many tools still not support yet - avoid duplicate FPI declarations - allow to point to the right version of a given DTD and to the corresponding entities and style sheets from only one place When splitting your CATALOG pointers in one file per DTD, you also somehow lose a global vision on all the catalogs that are installed on your system. This is why we have introduced the super-catalog, pointing to all the centralized catalogs on your system. It eases a lot scripting issues. The super catalog may be used as a default centralized catalog, for example when the DTD is not known, however it can't be guaranteed that there won't be any declaration conflicts if an application chooses to use this functionality. OASIS says that all the catalogs should be named "CATALOG" or "catalog". This was impossible to respect in /etc/sgml where you will have the centralized catalogs, because many files cannot hold the same name. Somehow it does not break those directives that much, because all the ordinary catalogs on your system would still be named "catalog". We also choose to specify "catalog" rathen than "CATALOG", while OASIS leaves the choice. We considered that we should encourage one of both versions, whichever it should be, because it made live simpler for everyone (scripts, maintainers, packagers, tools authors, ...). In this respect, LSB implementations could be considered as conformant to OASIS, while the contrary would not be true. R004 - Open Catalog usage for DocBook ------------------------------------- Directories like the ones holding Jade's or OpenJade's declarations and the ISO entities are on top level because they are not specific to any given DTD and can be used by two or more of them. Of course one may argue that Jade's or OpenJade's declarations contain the document type definition of what DSSSL is. But again what is important is the usage, not the formal definition, so it has no reason to go to a dsssl/ directory (which would also encourage packagers to put the stylesheets in, away from their dtd, which is not what we want). R005 - Configuration files -------------------------- This recommendation is voluntarily vague, to ease as much as possible the possibility to create SGML applications with not creativity restrictions with respect to configuration files - the catalog layout solves anyhow one of their major problems: find the files. R006 - Iso-entities ------------------- So far, the most confusion has been with the file names holding these very basic character entities. We have seen the following naming schemes: ISOamsa ISOamsb ... ISOamsa.ent ISOamsb.ent ... iso-amsa iso-amsb ... iso-amsa.gml iso-amsb.gml ... etc... There was a similar confusion for the Formal public identifiers describing these files. We have seen the following naming schemes: "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" "ISO 8879-1986//ENTITIES Added Math Symbols: Arrow Relations//EN" Again, we chose to avoid deciding not to decide. We had a lot of feedback from users suffering from this indecision. Even if technical workarounds exist, we would like to encourage one of these forms to emerge. R007 - Packages --------------- We are very far from providing inter-distribution compatibility at the package level, and it is likely that someone will get broken dependencies if he/she mixes packages coming from different distributions. This document will not try to fix package names nor proposed dependency declarations for DocBook distributions. We however wanted to point out a problem that may be encountered when packaging SGML or XML: the package numbering scheme. sgml-base-doc-1.99.2/.svn/pristine/d3/0000755000000000000000000000000012763406467014165 5ustar sgml-base-doc-1.99.2/.svn/pristine/d3/d3964f9dad9f60363c81b688324d95b4ec7c8038.svn-base0000644000000000000000000000000212763406467023151 0ustar 7 sgml-base-doc-1.99.2/.svn/pristine/ba/0000755000000000000000000000000012763406467014241 5ustar sgml-base-doc-1.99.2/.svn/pristine/ba/ba68a4e0e4550c7d800776258c1930641212d7f7.svn-base0000644000000000000000000000101112763406467022750 0ustar Document: sgml-doc-base Title: SGML Entity Management Author: Manoj Srivastava Abstract: This document provides guidelines for implementation dependent Entity management of SGML entities for Debian systems. Section: Debian Format: HTML Index: /usr/share/doc/sgml-base-doc/sgml_layout.html/index.html Files: /usr/share/doc/sgml-base-doc/sgml_layout.html/*.html Format: PDF Files: /usr/share/doc/sgml-base-doc/sgml_layout.pdf.gz Format: text Files: /usr/share/doc/sgml-base-doc/sgml_layout.txt.gz sgml-base-doc-1.99.2/.svn/pristine/7d/0000755000000000000000000000000012763406467014171 5ustar sgml-base-doc-1.99.2/.svn/pristine/7d/7d96cdbf057b24cacc8af388798e71ddf98cb4d9.svn-base0000644000000000000000000000116312763406467023634 0ustar #!/usr/bin/make -f #export DH_VERBOSE=1 PACKAGE = sgml-base-doc PKG_DOCS = sgml_layout.html sgml_layout.pdf sgml_layout.txt .SUFFIXES: .html .pdf .sgml .txt .sgml.html: debiandoc2html $< .sgml.pdf: debiandoc2latexpdf -p letter $^ .sgml.txt: debiandoc2text $^ check: check-stamp check-stamp: sgml_layout.sgml dh_testdir nsgmls -wall -E20 -gues $< touch $@ build: $(if $(findstring nocheck,$(DEB_BUILD_OPTIONS)),,check) $(PKG_DOCS) binary binary-arch binary-indep clean install: dh $@ override_dh_clean: $(RM) -r $(PKG_DOCS) sgml_layout.tpt dh_clean .PHONY: binary binary-arch binary-indep check clean install sgml-base-doc-1.99.2/.svn/pristine/75/0000755000000000000000000000000012763406467014112 5ustar sgml-base-doc-1.99.2/.svn/pristine/75/7587289ab2c562061e3c52b48d2766a42774f7b3.svn-base0000644000000000000000000002420112763406467022646 0ustar Recommendations for DocBook, SGML and XML processing ---------------------------------------------------- Introduction ------------ In a normalisation effort, about thirty people, including packagers of some Linux distributions, and developers of SGML related tools such as the SGML-Tools and DocBook Tools project, discussed informally and agreed on a series of recommendations that will be submitted as a draft to the Linux Standard Base project. A reference implementation will also be done as part of the DocBook-tools project. This document's redaction started as an attempt to end the nightmare of DocBook distributions, but it appeared quickly to be generic enough to apply to any SGML or XML DTD. Explanations about the reasons for all our choices are given in a separate document. Following a list of definitions, you will find a set of recommendations: R001 - SGML Directory layout R002 - DocBook Directory layout (standard names for directories, their contents) R003 - Open Catalogs usage for SGML R004 - Open Catalogs usage for DocBook (for the centralized catalogs and for the individual catalogs) R005 - Configuration files (other /etc/sgml files) R006 - ISO-entities (file names and FPI declarations) R007 - Packages (how to package this type of material) We'd like to thank the following people who have participated intensively in this normalisation effort: Camille Begnis (MandrakeSoft) <camille@mandrakesoft.com> Eric Bischoff (Caldera, KDE) <eric@caldera.de> Karl Eichwalder (SuSE) <ke@suse.de> Mark Galassi (DocBook-tools) <rosalia@lanl.gov> Jorge Godoy (Conectiva) <godoy@conectiva.com.br> Cees de Groot (SGML-tools) <cg@cdegroot.com> Jochem Huhmann <joh@revier.com> David Mason (RedHat, Gnome) <dcm@redhat.com> Manoj Srivastava (Debian) <srivasta@datasync.com> Norman Walsh (Sun, OASIS) <ndw@nwalsh.com> and all the other many people that helped with their own contribution. Definitions ----------- In the scope of this document, we will use the following terms: SGML application: Any program used to view, edit, convert, process or apply any kind of treatment to a document written using a SGML or XML DTD (Document Type Definition). This includes command-line utilities as well as GUI-based applications. SGML converter: A SGML application, or a part of a bigger SGML application, used to convert from a given SGML-based input format to a given output format. frontend: A part of a SGML converter used to analyse the input format backend: A part of a SGML converter used to analyse the output format helper: A stand-alone application used by a SGML converter to accomplish the conversion itself. Style sheets: Declarations or scripts that define formatting during the conversion process. They can be written in any style sheets language: DSSSL, FOSIs, XSL, ... Open Catalog: A set of directives defined by OASIS, mostly used for defining equivalences between FPIs (Formal Public Identifiers) and real file names (see TR9401:1997 on http://www.oasis-open.org). Centralized catalog: An Open Catalog that includes only comments and CATALOG directives pointing to other catalogs (or DELEGATE directives if supported). Super catalog: An Open Catalog pointing to all the centralized catalogs. Package: A set of files assembled together for distribution. It includes RPMs, DEBs and any other kind of packaging system. R001 - SGML Directory layout ---------------------------- /etc/sgml/ Configuration files, including centralized catalogs. It includes: *.conf: generic configuration files sgml-docbook.cat, tei.cat, ...: DTD-specific centralized catalogs catalog: the super catalog ... /usr/share/sgml/ Architecture-independent files used by SGML applications: Open Catalogs (not the centralized ones), DTDs, entities, style sheets, and other declarative files, if any. It is organized into DTD-specific subdirectories: docbook/ tei/ html/ ... At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /usr/share/xml and /etc/xml. R002 - DocBook Directory layout ------------------------------- This is the layout for a Jade-based or an Openjade-based system. DocBook applications based on other parsers, or even any other SGML application, can be based on this layout as well. In /usr/share/sgml, the upper level directories identify the DTD that is concerned. Things that are not DTD-specific go directly into /usr/share/sgml under their own directory. The lower level directories are package-related. They are also version-numbered. /usr/share/sgml/ sgml-iso-entities-8879.1986/ xml-iso-entities-8879.1986/ (the ISO entities) jade-1.2.1/ openjade-1.3/ ... (the parsers and DSSSL engines architecture-independent files) ... /usr/share/sgml/docbook/ sgml-dtd-3.1/ sgml-dtd-4.0/ xml-dtd-4.0/ (the DocBook DTD) dsssl-stylesheets-1.54/ xsl-stylesheets-1.12/ (DSSSL style sheets for DocBook) kde-customization-0.1/ gnome-customization-0.1/ ldp-customization-0.1/ (customized DTDs, entities and style sheets for the various projects) ... (version number examples are arbitrary in this list) R003 - Open Catalog usage for SGML ---------------------------------- Open Catalog files include: - the individual catalogs provided with the DTDs, sylesheets or entities. - the centralized catalogs used as central source of information that is specific to docbook, tei, or any other DTD - the super catalog that references indirectly all the available catalog files The centralized catalog file names must end in .cat and reside in /etc/sgml. They contain only comments and CATALOG directives pointing to the "real" catalogs, like: -- sample contents of /etc/sgml/foo-1.05.cat -- CATALOG /usr/share/sgml/foo/xml-dtd-1.05/catalog CATALOG /usr/share/sgml/foo/xsl-stylesheets-0.1/catalog One can use DELEGATE instead of CATALOG if this directive is known to be supported. The centralized catalogs are DTD-specific and can be version-numbered. Here are examples of such centralized catalogs: /etc/sgml/ sgml-docbook.cat sgml-docbook-3.1.cat sgml-docbook-4.0.cat xml-docbook-4.0.cat Version-less centralized catalogs could be only symbolic links to the latest version (or to any other older version). /etc/sgml/catalog is the "super catalog". It contains CATALOG pointers to all the centralized catalogs: -- sample contents of /etc/sgml/catalog -- CATALOG /etc/sgml/sgml-docbook.cat CATALOG /etc/sgml/xhtml.cat CATALOG /etc/sgml/mathml.cat One can use DELEGATE instead of CATALOG if this directive is known to be supported. It should not point to centralized catalogs that are merely symbolic links and therefore are already mentioned. The users should be able to define their own centralized catalogs and their own super catalog in their home directories: $HOME/.sgml-docbook.cat $HOME/.catalog The SGML applications are not supposed to use centralized catalogs, although their use is stronlgy encouraged: if other mechanisms allow one to locate the real catalogs, they can be used as well. However distribution packagers should always take care of feeding the right entries into the super catalog and the centralized catalogs. The interface for a script named "install-catalog" that does these maintenance tasks is described here: install-catalog --add|--remove <centralized_catalog> <ordinary_catalog> Example: install-catalog --add \ /etc/sgml/sgml-docbook-3.1 \ /usr/share/sgml/docbook/dsssl-stylesheets-1.54/catalog The other catalogs should be placed in subdirectories of /usr/share/sgml. They should all be named "catalog". They are the ones who do the real work of mapping the FPIs to file names (among other tasks). R004 - Open Catalog usage for DocBook ------------------------------------- This recomendation is merely a consequence of the preceeding recomendations. For a Jade- or Openjade-based distribution of DocBook, we suggest the following names. Again, other SGML or XML DTDs can be based on this structure. /etc/sgml/ sgml-docbook.cat xml-docbook.cat sgml-docbook-3.0.cat sgml-docbook-3.1.cat sgml-docbook-4.0.cat xml-docbook-4.0.cat /usr/share/sgml/sgml-iso-entities-8879.1986/catalog /usr/share/sgml/xml-iso-entities-8879.1986/catalog /usr/share/sgml/jade-1.2.1/catalog /usr/share/sgml/openjade-1.0/catalog /usr/share/sgml/docbook/sgml-dtd-3.0/catalog /usr/share/sgml/docbook/sgml-dtd-3.1/catalog /usr/share/sgml/docbook/sgml-dtd-4.0/catalog /usr/share/sgml/docbook/xsl-dtd-4.0/catalog /usr/share/sgml/docbook/dsssl-stylesheets-1.54/catalog /usr/share/sgml/docbook/xsl-stylesheets-1.12/catalog R005 - Configuration files -------------------------- Other configuration files may also reside in /etc/sgml, either DTD-specific or application-specific. Their name should end in ".conf" and they should follow ordinary rules for files residing in /etc as defined by LSB. The user should be able to redefine them in his/her home directory. Their syntax and purpose is not defined in this document. R006 - Iso-entities ------------------- The file names should be fixed to: ISOamsa.ent ISOamsb.ent ... The identifiers should be fixed to: "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" In the transitory period, symbolic links and duplicate declarations will be allowed as a means to preserve the compatibility with previous naming schemes. R007 - Packages --------------- C programs can get compiled with any version of a given compiler. SGML documents can't use any version of a given DTD. They need the corresponding DTD to reside on the same system, or at least to be reachable. The various versions of a given DTD in turn may imply certain versions of the style sheets. This leads to a unusual situation where the old DTDs and style sheets should not be replaced during a package update. We would like to make the solutions to achieve this aware to distribution packagers. They may choose to: - put the version number in the package name field (example: docbook-dtd-3.1-1.0.rpm) - not put the version number and use subpackages for each version sgml-base-doc-1.99.2/.svn/pristine/f8/0000755000000000000000000000000012763406467014174 5ustar sgml-base-doc-1.99.2/.svn/pristine/f8/f8efd3439db82e50c9e5432331fe2ba43dc9e15d.svn-base0000644000000000000000000000533012763406467023442 0ustar sgml-base-doc (1.99.2) UNRELEASED; urgency=low * NOT RELEASED YET -- Daniel Leidert (dale) Fri, 22 Jan 2010 01:42:53 +0100 sgml-base-doc (1.99.1) unstable; urgency=low * Upload to unstable to fix FTBFS. * debian/control (Standards-Version): Bumped to 3.8.3. (Build-Depends): Increased for dh level 7. (Depends): Fixed debhelper-but-no-misc-depends. * debian/compat: Bumped to 7. * debian/rules: Adjusted for dh level 7. -- Daniel Leidert (dale) Fri, 22 Jan 2010 01:18:03 +0100 sgml-base-doc (1.99.0) experimental; urgency=low * Makefile: Dropped build system. debian/rules and debhelper are enough. * debian/compat: Increased compatibility level to 5. * debian/control: Added Vcs*, Homepage and DM-Upload-Allowed fields. (Uploaders): Added myself. (Build-Depends-Indep): Moved debhelper to Build-Depends. Replaced tetex* packages by texlive packages (closes: #562307). (Standards-Version): Bumped to 3.8.2. * debian/rules: Rewritten in parts. Now contains all stuff from the Makefile. Added a check target. * debian/sgml-base-doc.doc-base (Document): Fixed. Thanks to lintian. * debian/sgml-base-doc.README.Debian: Renamed to debian/README.Debian. -- Daniel Leidert (dale) Sun, 12 Jul 2009 16:21:16 +0200 sgml-base-doc (1.16) unstable; urgency=low * debian/control: upgraded to Debian Policy 3.6.1 (no changes) * debian/control: changed 'Maintainer' to 'Debian XML/SGML Group ' and added current maintainer to 'Uploaders' -- Ardo van Rangelrooij Thu, 22 Apr 2004 07:54:27 -0500 sgml-base-doc (1.15) unstable; urgency=low * Removed document sources from binary package and indicated in README.Debian how to get the source package * debian/rules: moved debhelper compatibility level setting to 'debian/compat' per latest debhelper best practices * debian/control: changed build dependency on 'debhelper' to '(>= 4.1)' * debian/control: upgraded to Debian Policy 3.6.0 (no changes) -- Ardo van Rangelrooij Tue, 12 Aug 2003 21:02:30 -0500 sgml-base-doc (1.14) unstable; urgency=low * debian/rules: upgraded to debhelper v4 * debian/control: changed build dependency on debhelper accordingly * debian/rules: migrated from 'dh_movefiles' to 'dh_install' * debian/rules: split off 'install' target from 'binary-indep' target * debian/copyright: added pointer to license -- Ardo van Rangelrooij Sat, 10 Aug 2002 13:58:20 -0500 sgml-base-doc (1.13) unstable; urgency=low * Initial release as a separate package -- Ardo van Rangelrooij Sun, 17 Feb 2002 13:34:28 -0600 sgml-base-doc-1.99.2/.svn/pristine/36/0000755000000000000000000000000012763406467014107 5ustar sgml-base-doc-1.99.2/.svn/pristine/36/3656f81b827a0147f481270b28024c1951fcd7bf.svn-base0000644000000000000000000000150212763406467022704 0ustar This is the Debian package of the documentation for sgml-base. It was assembled by Ardo van Rangelrooij . It is currently maintained by Ardo van Rangelrooij and the Debian XML/SGML Group . ---------------------------------------------------------------------- Copyright of the sgml-base manual: Copyright (c) 1998 Manoj Srivastava This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. ---------------------------------------------------------------------- On a Debian system a copy of the GNU General Public License can be found in the file '/usr/share/common-licenses/GPL'. sgml-base-doc-1.99.2/.svn/pristine/e2/0000755000000000000000000000000012763406467014165 5ustar sgml-base-doc-1.99.2/.svn/pristine/e2/e29f288af9c780f4b00ba2c802a027deaac996f8.svn-base0000644000000000000000000000071512763406467023435 0ustar sgml-base-doc for Debian ======================== The source files for the documentation in this package can be obtained as follows: 1. Include a "deb-src" line in the "/etc/sources.list", e.g. deb-src http://ftp.us.debian.org/debian/ unstable main For more information on this see the manual page sources.list(5). 2. Download the source withthe following command: apt-get source sgml-base-doc -- Ardo van Rangelrooij sgml-base-doc-1.99.2/.svn/pristine/04/0000755000000000000000000000000012763406467014102 5ustar sgml-base-doc-1.99.2/.svn/pristine/04/044de9580c8a46547295b5dbec1ce4b9c49525a9.svn-base0000644000000000000000000000202412763406467023137 0ustar ------------------------------------------------------------------------------ To do list for sgml-base-doc ------------------------------------------------------------------------------ BUGS: ------------------------------------------------------------------------------ Number Description ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ WISHLIST: ------------------------------------------------------------------------------ Number Description ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ VARIOUS: ------------------------------------------------------------------------------ Description ------------------------------------------------------------------------------ * rewrite to reflect current * clean out what's not needed anymore ------------------------------------------------------------------------------ sgml-base-doc-1.99.2/.svn/pristine/6f/0000755000000000000000000000000012763406467014172 5ustar sgml-base-doc-1.99.2/.svn/pristine/6f/6f51150b8bb3cf4a19d149f26f8b95bcac2d972d.svn-base0000644000000000000000000000110212763406467023427 0ustar IMPORTANT NOTE -------------- This version of sgml-base starts the transition of /usr/lib/sgml to /usr/share/sgml. The documentation is not yet integrated into one single nice document with good examples and guidelines. This will definitely change in the near future. Also the support in the form of tools is still in its infancy. This version mainly only moves the catalogs into place and introduces a tool called update-catalog. Feedback -------- Please send me an email for bugs/suggestions/critics on this note. February 2001 Ardo van Rangelrooij sgml-base-doc-1.99.2/.svn/pristine/6b/0000755000000000000000000000000012763406467014166 5ustar sgml-base-doc-1.99.2/.svn/pristine/6b/6b389ab8a38104da46a704642e6fdf714fcc18cf.svn-base0000644000000000000000000000017012763406467023347 0ustar POLICY README sgml_layout.html sgml_layout.pdf sgml_layout.txt EXPLANATIONS.lsb RECOMMENDATIONS.lsb RECOMMENDATIONS.fhs sgml-base-doc-1.99.2/.svn/pristine/a8/0000755000000000000000000000000012763406467014167 5ustar sgml-base-doc-1.99.2/.svn/pristine/a8/a8f1a5ea07a1e93076c04057534d45726411e417.svn-base0000644000000000000000000000523012763406467022673 0ustar File system recommendations for SGML and XML layout --------------------------------------------------- Introduction ------------ In a normalisation effort, about thirty people, including packagers of some Linux distributions, and developers of SGML related tools such as the SGML-Tools and DocBook Tools project, discussed informally and agreed on a series of recommendations that will be submitted as a draft to the Linux Standard Base project. A reference implementation will also be done as part of the DocBook-tools project. This document addresses the FHS part of the project. This document makes several references to "catalogs": these files represent the dorsal spine of a SGML or XML system. They are mainly used to map things (that are called "entities" in SGML or XML terminology) into real file names. A catalog can reference other catalogs through pointer directives (CATALOG, DELEGATE). For more information, see the Open Catalogs standard at http://www.oasis-open.org. /etc/sgml/ ---------- In /etc/sgml one can find configuration files that describe the installed components of a SGML or XML system. Files found there include: *.conf: generic configuration files *.cat: DTD-specific centralized catalogs catalog: the super catalog The generic configuration files define high-level parameters of the SGML or XML system. The "centralized catalogs" are catalogs that reference through pointers all the other catalogs that are needed to use a given DTD. The referenced files include the DTD's catalog, style sheets catalogs, character entities sets catalogs, etc. All the files that are referenced reside somewhere under /usr/share/sgml. The "super catalog" references through pointers all the centralized catalogs. Unlike the centralized catalogs, it does not guarantee the absence of definition conflicts between referenced catalogs. At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /etc/xml. /usr/share/sgml/ ---------------- In /usr/share/sgml reside architecture-independent files used by SGML or XML applications: ordinary catalogs (not the centralized ones), DTDs, entities, style sheets, and other declarative files, if any. It is organized at top-level into DTD-specific subdirectories, when applicable: docbook/ tei/ html/ mathml/ ... Other files that are not specific to a given DTD may reside in their own directory. When we say "specific to a DTD", it does not mean that those files describe a DTD, but only that they are to be used with this DTD. At least for the present, all XML documents are also SGML documents, so it seems unnecessary to create /usr/share/xml. sgml-base-doc-1.99.2/.svn/pristine/06/0000755000000000000000000000000012763406467014104 5ustar sgml-base-doc-1.99.2/.svn/pristine/06/062f3e7ca0d654db5c85d736d083e1811c54a77f.svn-base0000644000000000000000000001273012763406467023131 0ustar SGML Entity Management Manoj Srivastava srivasta@debian.org This document provides a guidelines for implementation dependent Entity management of SGML entities for Debian systems. This defines the mapping of External Public Identifiers to System Identifiers. (In other words, this document covers the use of /usr/lib/sgml, entity naming, and catalog files. Copyright ©1998 Manoj Srivastava

This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.

Introduction and Scope

This document was written by Manoj Srivastava srivasta@debian.org with contributions from Mark W. Eichin eichin@kitten.gen.ma.us and Adam P. Harris aph@debian.org. This document is part of the sgml-base package.

This guideline is intended to be intepreted as SGML sub-policy (not official policy). While this document does not carry the weight of official policy, it is sufficient basis for the submission of bugs against a package. This may change at a latter date.

Entity Management is generally left up to the implementation, and hence there are no extant Standards that cover this. However, lack of an established convention would prevent different segments of the SGML subsystem from co-operating with each other, hence it is important that a policy be established so that SGML package maintainers may depend on other parts of the system behaving consistently.

Proposed mapping of public identifiers to system identifiers

SGML can refer to an external file (really an entity) with an external identifier: this is a public identifier or a system identifier, or both.

A typical public identifier looks like PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" where ISO 8879-1986 is the owner, ENTITIES is the text class and Added Latin 1 is the text description, and EN is language.

A system identifier looks like SYSTEM "htmlplus.dtd" where htmlplus.dtd is a system-specific identifier.

To map external identifiers to file names, one should first try the system identifier, as a file name, and then search entity catalog files and then search the list of file names derived from the public identifier. The catalog format is according to SGML/Opens resolution on entity management. The catalog consists of a series of entries and comments. A comment is delimited by -- like in a markup declaration.

The fallback derivation of the file name is modelled after the sgmls environment variable SGML_PATH, and Emacs psgml mode's sgml-public-map variable. There does not seem to be any official standards (this is left to the implementation), so this standard is simply an abstraction of real-world practice of SGML tools, and shall now be the standard for Debian systems, since this is the convention currently followed by all applications currently in Debian.

Contiguous white space is compacted to a single space and replaced with an underscore (_); the characters / to % are also replaced with _. The text class is down-cased. The language specifier (i.e., //EN) and anything following it should be removed.

Location of miscellaneous files

There are a number of other files, though not entities referenced by Document instances, are still required by the SGML subsytem to parse or validate the document. These files are also covered by this document.

Declaration Files: Any declaration file should be put in /usr/lib/sgml/declaration

Notations: These files go in /usr/lib/sgml/notation.

Examples

A few public and system identifiers pairings are shown below. PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" /usr/lib/sgml/ISO_8879-1986/entities/Added_Latin_1 "ISO 8879-1986//ENTITIES Added Math Symbols: Arrow Relations//EN" /usr/lib/sgml/ISO_8879-1986/entities/Added_Math_Symbols:_Arrow_Relations "-//IETF//DTD HTML Level 3//EN//3.0" /usr/lib/sgml/IETF/dtd/HTML_Level_3.0 "-//IETF//DTD HTML Strict Level 3//EN" /usr/lib/sgml/IETF/dtd/HTML_Strict_Level_3 "-//USA-DOD//DTD Table Model 951010//EN" /usr/lib/sgml/USA-DOD/dtd/Table_Model_951010

The first four actually exist in Debian.

sgml-base-doc-1.99.2/.svn/pristine/74/0000755000000000000000000000000012763406467014111 5ustar sgml-base-doc-1.99.2/.svn/pristine/74/7448eaf4b675c022bc7d512cee457d7bbf59bc8b.svn-base0000644000000000000000000000173612763406467023450 0ustar Source: sgml-base-doc Section: doc Priority: optional Maintainer: Debian XML/SGML Group Uploaders: Ardo van Rangelrooij , Daniel Leidert (dale) Standards-Version: 3.8.3 Build-Depends: debhelper (>> 7.0.50~) Build-Depends-Indep: debiandoc-sgml, ghostscript, libpaperg, sp, texlive, texlive-latex-extra Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/sgml-base-doc/ Vcs-Svn: svn://svn.debian.org/svn/debian-xml-sgml/packages/sgml-base-doc/trunk/ Homepage: http://debian-xml-sgml.alioth.debian.org DM-Upload-Allowed: yes Package: sgml-base-doc Architecture: all Conflicts: sgml-base (<= 1.12) Replaces: sgml-base (<= 1.12) Depends: ${misc:Depends} Suggests: sgml-base (>= 1.13) Description: Documentation for sgml-base This package contains the documentation for sgml-base, providing the SGML infrastructure directories and catalog file support, in HTML, PDF and plain text format. sgml-base-doc-1.99.2/.svn/pristine/8c/0000755000000000000000000000000012763406467014171 5ustar sgml-base-doc-1.99.2/.svn/pristine/8c/8ce0a49f6993a66576a4b766a026487424e1b2f2.svn-base0000644000000000000000000000570712763406467023021 0ustar Debian SGML/XML Policy (draft) ============================== Currently, the policy is spread over several documents: - RECOMMENDATIONS.lsb - EXPLANATIONS.lsb - RECOMMENDATIONS.fsh - "SGML Entity Management" - this file In the near future this will all be integrated into a single official document, with the exception of RECOMMENDATIONS.fsh which will be a part of FHS v2.2. Besides the directory structure described in RECOMMENDATIONS.lsb, we will also support a non-versioned directory structure as proposed by Mark Johnson (excerpt from his message on debian-sgml): -- Directory Structure Comment: --------------------- On the proposed directory structure -- grouped by classes of dtds rather than file function: -Current dir structure: /usr/[share or lib]/sgml/ dtd/ stylesheet/ entities/ -Proposed: /usr/share/sgml/docbook/ sgml-dtd-3.1/ sgml-dtd-4.0/ xml-dtd-4.0/ (the DocBook DTD) dsssl-stylesheets-1.54/ xsl-stylesheets-1.12/ Wouldn't a hybrid of the two make much more sense? Something like: /usr/share/sgml/docbook/ dtd/ stylesheet/ entities/ The proposed structure looks unnecessarily messy, and harder to maintain. -- Package dependencies -------------------- All SGML and XML packages that provide a DTD or entity description file have to depend on the "sgml-base" package. This package implements the necessary infrastructure as described in the files RECOMMENDATIONS.lsb and RECOMMENDATIONS.fsh. Please don't modify the super catalog and the centralized catalogs directly in the postinst/prerm scripts of your package. Please use update-catalog(8) for that purpose. Example ------- Here is a simple example: Consider the package "foo" which provides the SGML DTD foo.dtd and an entity description file "foo-general". The package installs the following files: /usr/share/sgml/foo/sgml-dtd-/dtd/foo.dtd /usr/share/sgml/foo/sgml-dtd-/entities/foo-general /usr/share/sgml/foo/sgml-dtd-/catalog The catalog file can look like this: DOCTYPE foodoc foo/sgml-dtd-/dtd/foo.dtd ENTITY %foo-general foo/sgml-dtd-/entities/foo-general That's the postinst script: #!/bin/sh set -e if [ "$1" = configure ] then CENCAT=/etc/sgml/foo-.cat ORDCAT=/usr/share/sgml/foo-/catalog update-catalog --add $CENCAT $ORDCAT update-catalog --add --super $CENCAT fi #DEBHELPER exit 0 and the prerm script: #!/bin/sh set -e if [ "$1" = remove ] then CENCAT=/etc/sgml/foo-.cat ORDCAT=/usr/share/sgml/foo-/catalog update-catalog --remove --super $CENCAT update-catalog --remove $CENCAT $ORDCAT fi #DEBHELPER exit 0 Please check the update-catalog(8) manpage for details. Feedback -------- Please send me an email for bugs/suggestions/critics on this policy. February 2001 Ardo van Rangelrooij sgml-base-doc-1.99.2/.svn/format0000644000000000000000000000000312763406467013226 0ustar 12