| Previous | Table of Contents | Next |
The SGML Declaration
This declaration tells the processing system about character sets and control information, and also about any limitations of processing power. The originators of SGML wanted any machine, even those with limited processing power, to be able to run SGML applications. This declaration can tell the processing system the parameters it must assume to do its job.
Since most current generation computers have sufficient processing power to run SGML applications, it will probably not be necessary for you to deviate from what is called the Reference Concrete Syntax. This is the most commonly used set of parameters for SGML processing systems. You can find a copy at:
- ftp://ftp.ifi.uio.no/pub/SGML/declaration
Many systems assume the reference concrete syntax when you don’t specify another, and some systems even prohibit you altogether from specifying another syntax. Thus, you may avoid ever having to define parameters outside this widely used default, but in case you must, the basics are given in table 10.3.
| Part of Declaration | Description |
|---|---|
| <!SGML “ISO 8879:1986” | Tells parser markup to conform to the ISO standard version of SGML. |
| CHARSET | Includes base character set (BASESET)—usually standard ASCII—and described character set (DESCSET)—those character numbers parser is instructed to recognize. |
| CAPACITY | Defines amount of memory needed to parse the documents. This portion is ignored by most parsers today because of sufficient computing power. |
| SCOPE | Scope of concrete syntax: can be either DOCUMENT or INSTANCE. The latter means concrete syntax used in prologue to document and another declared concrete syntax applies to the document instance. |
| SYNTAX | This is where reference concrete syntax starts and ends—this portion defines eight values: SHUNCHAR CONTROLS (unsupported characters), BASESET and DESCSET (base character set and described character set), FUNCTION NAMECASE (specifies function characters), NAMING (rules for naming tags), NAMECASE (specifies whether uppercase and lowercase names are equivalent in elements and entities), DELIM (makes it possible to change values of standard delimiters in SGML), and QUANTITY (tells parser to watch certain quantities like length of tag names). |
| FEATURES | Defines markup minimization for processing system. |
| APPINFO | Specifies information about processing application system, such as HyTime. |
| > | Closing delimiter for SGML declaration. |
Tip:
The likeliest items that you may wish to modify in the SGML declaration are specific values such as the length of attribute values (literals), the length of tags, and the nesting level of open tags that is allowed. Desired optional features are sometimes also useful.
It should be very rare that you ever need to modify your processing system’s SGML environment in the SGML declaration. Before you consider doing so, check the public domain for existing SGML declaration alternatives that you might use. CALS, for example, modifies the reference concrete syntax to support long file names. Other alternatives are freely available. Check out the SGML archives listed at the following URL:
- http://www.sgml.com/sgmlig/Appendix6.html
The DOCTYPE Declaration
The DOCTYPE (or Document Type) declaration serves to associate an SGML document (or document instance) with its corresponding DTD. Although a document instance can include its corresponding DTD, it’s often more practical to simply reference it through the DOCTYPE declaration.
The following illustrates the components of the DOCTYPE declaration:
)
The COMMENT Declaration
Comments can be included within a DTD or a document instance by the use of a COMMENT declaration. It’s a simple declaration. By including it, you’re able to include comments that you want any and all SGML processing systems to ignore (or not process).
You may ask, “Why include comments if they’re not processed?” Good question. Their primary purpose is to make SGML objects (such as DTDs and document instances) intelligible to you and I rather than the machine processing them.
For example, you can use comments to separate the various sections of a DTD so it’s easier to read and understand. After all, what’s crystal clear to you when you develop a DTD might seem a little cryptic when you go back to modify it in a few years. The syntax of the COMMENT declaration follows:
)
Note:
Because you have start and stop indicators for comments, you can span multiple lines with comments.
Comments are also useful in building descriptive headers that can be used to describe a DTD, explain its revision history (with dates and authors), and include other useful information for describing its role and purpose. If the DTD is a fragment called by other DTDs, this can be described as well, along with a list of the DTDs that call it.
You can also include comments nested within other SGML declarations. For example, if you want to note that an element had been modified on a certain date, you can include a comment within the element declaration. In this case, you do not include separate MDO and MDC notation for the comment itself; rather you indicate the start and end of the comment through double hyphens alone:
<!ELEMENT section - o (title,(para+),epilog?)
-- modified by BH 9/24/94 -- >
| Previous | Table of Contents | Next |