---

About This Report

This report documents the design of the XML specification DTD. This is the first release of the report, corresponding to the DTD with the FPI "-//W3C//DTD Specification::19980910//EN".

Purpose and Scope

This report describes the DTD used for World Wide Web Consortium (W3C) specifications and notes related to XML.

Following are the major contributors to the DTD design:

	Jon Bosak, Sun (XML chair)
	Tim Bray, Textuality and Netscape (XML co-editor)
	Dan Connolly, W3C (W3C staff contact)
	Eve Maler, ArborText (DTD maintainer)
	Gavin Nicol, Inso (DOM member)
	C. Michael Sperberg-McQueen, University of Illinois (XML co-editor)
	Lauren Wood, SoftQuad (DOM chair)
	James Clark (XSL editor)

How to Use This Report

This report is organized as follows:

• Chapter 1 lists the sources of input used during the DTD design effort, describes the project design parameters, and describes global outstanding issues. Read this to understand the basic principles underlying the design results and to review the issues.

• Chapter 2 through Chapter 5 contain the markup models for the DTD, and Chapter 6 describes information linking relationships, nontextual data formats, and special symbols that the DTD encodes. Read these chapters to understand how the markup will be used with World Wide Web Consortium XML information, and the reasons for their design.

  Note that, where appropriate, some processing expectations have been documented for the markup. This information is not to be considered a complete style specification; it simply records known requirements.

• Chapter 7 contains the common categories of elements and the commonly used element mixtures in content models. Read this to understand the "mixture" content models described in Chapter 3, Chapter 4, and Chapter 5.

How to Read Elm Tree Diagrams

To understand the graphical "elm tree diagrams" used in this report, use the following legend.

---

Section 1 Introduction

Following is information on the sources of analysis input, the design principles governing the markup model, the implementation principles governing its expression in DTD form, and outstanding issues.

---

1.1. Catalog of Analysis Inputs

The following have been used as analysis input in designing the DTD:

• Original XML specification DTD, jointly developed and revised by Michael Sperberg-McQueen, Tim Bray, and Jon Bosak

• Michael's SWEB documentation

• The XML specification

• The XLink and XPointer specifications

• The XML/SGML comparison note

• The DOM specifications

---

1.2. Design Principles

Following are the design principles governing the markup model of the DTD.

---

1.2.1. Scope

Although the DTD has come to be called "XMLspec," it is intended for W3C working drafts, notes, recommendations, and all other document types that fall under the category of "technical reports."

The DTD is responsible for covering three main aspects of XML technical reports:

• Basic W3C technical report structure and content, including paragraphs, lists, cross-references, and so on

• Structure specific to the XML-related family of W3C technical reports, such as EBNF productions and validity constraints

• Proper headers and metadata for W3C technical reports

---

1.2.2. Focus

The DTD is intended to support the following functions, in order of priority:

1. Production of technical reports

   First and foremost, the DTD should facilitate hassle-free production and publication. Many of the documents in the scope are made available in several output forms, including source XML and derived HTML, RTF, and PostScript. It is important to produce these outputs in a form that meets W3C requirements, and produce them quickly in order to speed the W3C publication release process. Also, it may be useful to extract different parts of the document content (for example, just the productions) for distribution.

2. Creation and modification of content

   The DTD should provide an intuitive, efficient interface to the creation process. This means that the DTD shouldn't be overly large or complicated, but that it should provide support for information structures using the jargon, and to the depth, that authors will tend to understand the information.

3. Review of content

   To a lesser degree, the DTD should support the informal workflow that goes on when co-editors pass around drafts for review. To this end, the DTD should provide markup for editor "communication" inside the document source.

4. Proof of concept of XML publishing

   Finally, where possible, this DTD and its associated applications should use good XML practice and conforming XML tools, because many will look to this application as an example.

---

1.2.3. Presentation Independence

The DTD should avoid presentational markup where possible. Sometimes this principle comes into conflict with the production focus, but in general, presentation independence helps serve the goal of production of multiple outputs. In any case, egregious examples of formatting-specific markup should be avoided.

---

1.3. Information for DTD Maintainers

The following information gives background on implementation decisions.

---

1.3.1. Versioning and Updates

This DTD is given a formal public identifier in the following pattern:

-//W3C//DTD XML Specification::yyyymmdd//EN

The current version is identified as:

-//W3C//DTD Specification::19980910//EN

It is a goal to avoid backwards-incompatible changes where possible, but occasionally this is necessary. Always review the change history in any new version of the DTD carefully before deploying it.

Currently, DTD changes are at the discretion of the maintainer and the heaviest users of the DTD. A more formal procedure may be put in place by the W3C later.

---

1.3.2. Naming and Coding Conventions

The element names from the original DTD on which XMLspec was based were mostly kept; changes were made in a few cases only to rationalize the naming scheme.

Hyphens are avoided, except in the "w3c-" prefix.

Whitespace and tabs are used relatively sparingly to enhance readability; excessive whitespace is avoided in the interest of a compact and "unthreatening" DTD.

---

1.3.3. Parameter Entity Typology

Parameter entities are used in several different capacities in the DTD. To indicate their different roles, unique suffixes are used as follows:

descrip.att

The name, declared value, and default value specifications for a set of one or more attributes.

Some descriptions may have a sub-suffix, such as -req, which means that the attribute (or one of the attributes) in question is required.

descrip.class

A set of related elements that are typically available as options in certain content model "free mixtures" (repeatable-OR groups). These entities are referenced from within descrip.mix entity declarations, content models, and content model exceptions.

If you add a new standalone or phrase-level element, make sure that you add it to the appropriate class entity, or create a new class for it. If you create a new class, incorporate references to that class in the appropriate mixture entity declarations.

descrip.mix

A set of elements that are available to writers in certain contexts as a "free mixture" (repeatable-OR group). These entities are referenced from within content models.

descrip.pcd.mix

A set of #PCDATA and elements that are available to writers in certain contexts as a "free mixture" (repeatable-OR group). These entities are referenced from within content models. The presence of #PCDATA makes these "mixed" content models, which means that document creators can type regular text here and that downstream applications will need to take account of whitespace found here.

local.descrip.class

An empty placeholder that is available to be used in extending an element class.

descrip.mdl

A content model fragment (other than a "free mixture") that is common or customizable.

The goal in naming the entities was to be consistent and brief, without losing readability. The keyword indicating the entity type always appears last because the location of an entity reference will already give a clue as to the entity type, and so this is not the information that needs to be seen first when the DTD is read. This naming scheme also allows for easier searching.

---

1.3.4. XML Usage

The DTD conforms to XML V1.0. The intent is to make available an XML-compliant version of the DTD, even though some editors may choose to work and interchange in full SGML.

While XLink is used for all URL-style linking, the IDREF addressing mechanism is still used heavily for internal links. As support for the #id(xxx) XPointer construct grows, we will consider moving to this style of addressing for internal linking.

---

1.3.5. Parameterization

The DTD is beginning to be used by other W3C Working Groups. While this DTD was designed with the needs of XML technical reports firmly in mind, quite a lot of the markup design would be useful for technical reports produced by others in the W3C. Therefore, the DTD has been parameterized to allow for:

• Modification of certain content models that are likely to be subject to personal and Working Group preference

• Addition of new elements at the "standalone" and "phrase" levels

• Some limited removal of existing elements at the "standalone" and "phrase" levels

If it is found that the DTD can be made more widely useful solely by heavier parameterization, it would probably be worth it to add the new parameters.

Heed the following advice if you plan to develop a variant of the DTD:

• Plan and document both the substance of your changes and the reasons for them.

• Build variants only by redefining the original parameter entities, if possible; don't edit any of the original DTD files.

• If you plan to interchange your files with other DTD users, favor markup changes that place tighter validation restrictions on documents (subsets), rather than changes that would allow instances that no longer conform to the standard DTD (extensions).

• Avoid confusion by using a different formal public identifier for your DTD variant if you have changed any element or attribute markup characteristics. You may want to indicate the derivation with an identifier that uses the following pattern:

  -//owner-ID//DTD XML Specification 19980910-Based your-descrip-and-version//lang

---

1.4. Issues

Following are outstanding global issues:

1. Consider adding a syntactic metavariable element, so that emph doesn't get abused too badly.

2. Consider adding an optional href to name and affiliation, and allowing them and email in regular text.

3. Revise XLink usage as necessary.

4. Dan's latest word on the appropriateness of external cross-references in specifications is that all references should be to a bibliography entry, and then the bibliography entry should point to the Web resource (if possible). This would suggest that we should freely allow bibref, but allow loc only in the special header fields such as "Latest Version" and in bibliography entries. Should we try to migrate over to this scheme?

5. Perhaps related is the fact that titleref is freely allowed in paragraphs as well as in bibl. Since titleref is like a restricted or subclassed form of loc, it may also be obsolescent. In addition, titleref appears to duplicate the hypertext function of bibl (or maybe it's the other way around, since it may be inappropriate to make the entire contents of bibl "hot").

6. Dan has requested that the element type names in this DTD match HTML wherever possible. The question is, how much is possible? About a dozen of the element types in this DTD are strongly reminiscent of element types in HTML. However, in all cases, there are subtle differences (sometimes simply amounting to different subelements allowed inside the element in question). Should the element type names be made to match?

   Following are the potential correspondences:

   XML specification DTD	HTML	Comments
   loc	a	The semantic is slightly different
   p	p	No change needed
   ulist	ul
   item	li
   olist	ol
   slist	sl	For consistency; not HTML-based
   glist	dl	Contents are significantly different
   gitem	dli	For consistency; not HTML-based
   label	dt
   def	dd
   blist	bl	For consistency; not HTML-based
   eg	pre	The semantic and contexts are different
   graphic	img
   emph	em

7. If a glossary list is used to organize term definitions, how can termdef properly be used? Currently, at least in the XLL-related drafts, the contents of the label element are surrounded with a termdef element and a term element isn't provided, while the actual definition text in def goes unmarked-up as such.

8. Do Steve Deach and James Clark want to add any XSL-specific markup features?

9. Should the nt element be empty, and have its content generated by reference to the production's lhs? This would avoid redundancy.

10. Some users have requested that, when specifications are published, they also include a separate ASCII document with just the EBNF productions.

---

1.5. DTD Change History

Following is the change history for the DTD. Note that you can search the DTD file for "#" in the first column to see change history comments.

1997 August 18

Did a major revision.

1997 September 10

Updated FPI.

Removed namekey element and put key attribute on name element.

Made statusp element and supporting entities.

Added slist element with sitem+ content.

Required head on scrap and added new bnf subelement.

Added an xnt element and allowed it and nt in regular text and rhs.

Removed the ntref element.

Added back the com element to the content of rhs.

Added a key attribute to bibl.

Removed the ident element.

Added a term element to be used inside termdef.

Added an xtermref element parallel to termref.

Beefed up DTD comments.

1997 September 12

Allowed term element in general text.

Changed bibref to EMPTY.

Added ref.class to termdef.pcd.mix.

1997 September 14

Changed main attribute of xtermref from def to href.

Added termdef.class to label contents.

1997 September 30

Added character entity module and added new entities.

Removed p from appearing directly in self; created %p.mix;.

Added inform-div (non-normative division) element.

Fixed xtermref comment to mention HREF, not ref.

Extended orglist model to allow optional affiliation.

Modified author to make affiliation optional.

Added %speclist.class; and %note.class; to %obj.mix; and %p.mix;.

Added %note.class; and %illus.class; to %termdef.pcd.mix;.

Added unused HTML elements.

Put empty system ID next to public ID in entity declarations.

1997 October 14

Fixed "unused" div content model to move nested div to mixture.

1997 October 16

Added SGML Open Exchange tables.

1997 November 28

Added support for prodgroup and its attributes.

Added support for HTML tables.

Added loc and bibref to content of com.

Added loc to general p content models.

Allowed p as alternative to statusp in status.

Added non-null system IDs to external parameter entity declarations.

(Modified the SGML Open table module to make it XML-compliant.)

(Modified the character entity module.)

1997 December 29

Moved #PCDATA occurrences to come before GIs in content models.

Removed use of the SGML Open table module.

Added xspecref element.

Ensured that all FPIs contain 4-digit year.

(Modified the character entity module.)

1998 March 10

Merged the character entity and table modules into the main file.

Added ldquo and rdquo entities.

Added common attributes to prodgroup.

Made the email element in header optional.

Removed reference to the SGML Open table model.

Added ednote element.

Added quote element.

Updated XLink usage to reflect 3 March 1998 WD.

Added "local" entities to the class entities for customization.

Parameterized several content models to allow for customization.

1998 March 23

Cleaned up some comments and removed some others.

Added xml:space semi-common attribute to eg and bnf elements.

Added show and embed attributes on all the uses of href.

Added %common.att; to all HTML table elements.

Added a real URI to the "typical invocation" comment.

1998 May 14

Fixed mdash, ldquo, and rdquo character entities.

Switched to the full HTML 4.0 table model.

Removed htable/htbody elements and replaced them with table/tbody.

Added issue element to %note.class; and declared it.

Allowed prevlocs and latestloc in either order.

Added key-term, htable, htbody, and statusp as unused elements.

Removed real statusp element in favor of plain p.

1998 May 21

Declared generic constraint and constraintnote elements.

Added constraintnote to %note.class;.

Added constraint to %eg.pcd.mix; and prod content model.

1998 August 22

Fixed %illus.class; to mention table instead of htable.

Added definitions to %illus.class; for DOM model.

Added DOM definitions element and its substructure.

Updated XLink usage in %href.att; to use xlink:form and #IMPLIED.

Added clarifying comments to HREF-using elements.

---

Section 2 Common Attributes

This chapter describes the markup design for attributes that appear on multiple element types in substantially similar form.

---

2.1. Attributes Appearing on Every Element

The following attributes are truly "common"; they are available on every element type and have the same basic meaning everywhere.

---

2.1.1. id Attribute

Description

The id attribute is for uniquely identifying an element so that it can be linked to from elsewhere. The id attribute is declared as type ID.

The id attribute appears on every element. Its value is optional on most elements; however, a value is required on the following elements because they are always meant to serve as the target of a link:

	issue
	wfcnote
	vcnote
	constraintnote
	prod
	termdef

The %common.att; entity is used for those elements that don't require an id attribute, and the %common-idreq.att; entity is used for those elements that do require an id attribute.

Processing Expectations

ID values may be linked to; each linking element has its own processing expectations.

Rationale

IDs are generally useful in document management. Thus, they are made available on every element, just in case. For those elements that generally serve as targets of links, IDs are made mandatory.

Note that an attribute with type ID can be used both by IDREF attributes and by XPointers. The unique identification of an element does not presume a linking solution.

---

2.1.2. role Attribute

Description

The role attribute is for extending an element type by giving it an additional descriptive keyword, which a stylesheet can act on if necessary. The role attribute is declared as NMTOKEN. The %common.att; and %common-idreq.att; entities both contain role, in optional form.

Processing Expectations

Role values may or may not be operated on by stylesheets.

Rationale

Roles help extend the life of a DTD between revisions and serve as a way to prototype new DTD extensions.

Note that the XMLspec DTD does not prescribe values for, or dictate usage of, the role attribute in any way. This attribute is intended for extensions to the "official" application. Thus, where an element type is expected to be subclassed on a regular basis, it is given an additional non-role attribute to serve this purpose.

---

2.2. Attributes Appearing on Selected Elements

The following attributes each appear on a few similar elements, and generally have similar meaning in each case.

See Section 4.5.4 for information about the common attributes associated with tables.

---

2.2.1. Key Attribute

Description

The key attribute provides a string that can be used in sorting, indexing, and general description, when it is suspected or known that the element content won't suffice.

The key attribute appears on the following elements:

	name
	bibl

Processing Expectations

The value of the attribute is used in sorting, indexing, or generating cross-reference text. See the sections on the individual elements for more information.

Rationale

It was felt that a subelement solution to the problem of sorting (in the case of name) was not ideal, because you need to surround some existing element content with the sorting subelement, and the existing content may not be suitable for sorting. (This is the same problem that index-term markup has.) We decided that an attribute would be more effective and less intrusive.

---

2.2.2. Definition Attribute

Description

The def attribute points to the element where the relevant definition can be found, using the IDREF mechanism. The %def.att; parameter entity is used for optional def attributes (of which there are currently none), and the %def-req.att; parameter entity is used for required def attributes.

The def attribute appears on the following elements, and is required on all of them:

	wfc
	vc
	constraint
	nt
	termref

Processing Expectations

The content of this element should allow the user to link to the definition.

Rationale

The IDREF mechanism was used for now, until the XPointer #id(xxx) mechanism is more widely supported.

Though %def.att; isn't used for now, it's coded in case it's needed later.

---

2.2.3. Reference Attribute

Description

The ref attribute points to the element where additional information can be found, using the IDREF mechanism. The %ref.att; parameter entity is used for optional ref attributes (of which there are currently none), and the %ref-req.att; parameter entity is used for required ref attributes.

The def attribute appears on the following elements, and is required in both cases:

	bibref
	specref

Processing Expectations

The content of this element should allow the user to link to the additional information.

Rationale

The IDREF mechanism was used for now, until the XPointer #id(xxx) mechanism is more widely supported.

Though %ref.att; isn't used for now, it's coded in case it's needed later.

---

2.2.4. Hypertext Reference Attribute and Source Attributes

Description

The href attribute points to the resource where more information or source data can be found, using the XLink simple linking mechanism. For some purposes, the href attribute is associated with additional XLink attributes (which set the desired behavior to show="new" and actuate="user"). The %href.att; parameter entity is used for optional href attributes and their related XLink attributes, and the %href-req.att; parameter entity is for required href attributes and their related XLink attributes.

The href attribute appears on the following elements, where its value is required:

	email
	loc
	xnt
	xtermref

The href attribute also appears on the following elements, where its value is optional:

	bibl
	titleref

The source attribute points to the file where the graphic source data can be found; it is always required. The %source-req.att; parameter entity is used for the source attribute and its related XLink attributes (which set the desired behavior to show="embed" and actuate="auto"). The source attribute appears on the following element:

graphic

Processing Expectations

In general, the content of elements with an href attribute should allow the user to link to the resource. The graphic element should pull in the graphic and display it in place. These behaviors are indicated by the use of the appropriate XLink show and actuate attributes.

For detailed information about processing expectations and how to distinguish among the various href-using elements, see Section 6.1.

Rationale

For inter-document links, it made more sense to use XLinks than any other method.

---

Section 3 Document Hierarchy and Metadata Structures

This section describes the major document hierarchy structures:

	spec
	header

---

3.1. Overall Specification Structure (spec)

Description

The spec element contains, in order, a header; an optional front; a body; and an optional back.

The header provides metadata about the specification document (see Section 3.2 for more information). The front matter is for prefatory material. The body matter is primary content. The back matter is supplementary content. All three are organized into divisions.

The elements front and body contain one or more div1 elements. The main element for structuring content is div1, the equivalent of a preface, chapter, or appendix. It can be subdivided to three additional levels, down to div4. At each level, the division contains a head (title), optionally followed by a mixture of standalone elements (see Table 7-1), optionally followed by the next level of subdivision (except in the case of div4).

The back element contains div1 and/or inform-div1 (non-normative or informational division) elements. If both are present, the normative divisions must appear first. The back element cannot be empty.

Processing Expectations

Divisions are expected to be numbered, and a report of the numbers and heads should normally be made into a Table of Contents before any front content.

Rationale

Elements serving the same function were merged to make a cleaner design.

The original text element, which wrapped all the non-header content, was removed because it didn't add anything to the structure, and its meaning ("a text") doesn't seem very relevant to W3C specifications. The original header contents have been consolidated under the header element, which meant that the original front element was no longer required because its titlepage contents have been done away with. The original backtabs element was removed, as agreed.

The original type attributes on the division elements were removed, as agreed.

Here is where it becomes apparent that the original "special lists" were removed from their special place in the division content models.

---

3.2. Specification Header (header)

Description

The header contains an ordered series of metadata elements:

title

The title of the technical report, for example, "Extensible Cheese Language (ECL)".

This was previously the wd-title element. It contains character data (see Table 7-2).

subtitle (optional)

The subtitle of the technical report, if it has one. It contains character data (see Table 7-2).

version

The version of the technical report, for example, "Version 4.0". It contains character data (see Table 7-2).

w3c-designation

The code by which the technical report is known in URIs and such, for example, "WD-xcl-991231".

This was previously the wd-num element. It contains character data (see Table 7-2).

w3c-doctype

The full name for the type of W3C technical report, for example, "World Wide Web Consortium Working Draft" or "World Wide Web Consortium Note". It contains character data (see Table 7-2).

pubdate

The day (optionally), month, and year of publication of the document, separated out into day, month, and year elements. This should be the date on which the final text has been handed over to the W3C for official publication. Note that in internal interim drafts, you may want to provide a notice explaining the situation. The day, month, and year elements contain character data (see Table 7-2).

This was previously the wd-date element.

notice (optional and repeatable)

A generic notice to readers, for example, "This draft is for public discussion." You can add as many notices as are required.

The notice element contains a mixture of standalone elements (see Table 7-1).

publoc

The one or more Web resources corresponding to the different published forms (for example, XML, HTML, and PostScript) of this technical report. It contains one or more loc elements.

The content of each loc element should be a URI in the W3C style, which requires that the .htm or .html extension not be shown. The element also has a required href attribute, where a form of the URI that is suitable for actual Web access is supplied.

This was previously the thisver element.

prevlocs (optional; can appear after latestloc)

The one or more Web resources corresponding to the previously published versions of this technical report. It contains one or more loc elements. If there are no previous versions, the prevlocs element itself should not be provided.

The content of each loc element should be a URI in the W3C style, which requires that the .htm or .html extension not be shown. The element also has a required href attribute, where a form of the URI that is suitable for actual Web access is supplied.

This was previously the previousver element.

latestloc (optional; can appear before prevlocs)

The one or more Web resources corresponding to the latest version of this technical report. It contains one or more loc elements.

The content of each loc element should be a URI in the W3C style, which requires that the .htm or .html extension not be shown. The URI should also not contain a datestamp; the W3C staff should arrange for this URI to be symbolically linked to the datestamped version. The element also has a required href attribute, where a form of the URI that is suitable for actual Web access is supplied.

This was previously the latestver element.

authlist

The list of editors contributing to the document. It contains one or more author elements, each of which contains a name (has an optional key attribute), followed by an optional affiliation, followed by an optional email. The last requires an href attribute. The name, affiliation, and email elements contain character data (see Table 7-2).

This was previously the authors element. The affiliation element is optional because some editors may not be affiliated with any organization. The email element is optional to help avoid spamming of the editors.

status

A description of the status of the document, following W3C rules. This element contains a normal mixture of standalone elements (see Table 7-1)

abstract

A brief description of the document contents. It contains a mixture of zero or more standalone elements (see Table 7-1).

pubstmt (optional)

A brief bibliographic statement about this publication according to Text Encoding Initiative rules, for example, "Burlington, Seekonk, et al.: World-Wide Web Consortium, XML Working Group, 1999." It contains a mixture of standalone elements (see Table 7-1), so the example text would have to be inside a p.

sourcedesc (optional)

A brief statement about the original source for this document, for example, "Created in electronic form." It contains a mixture of standalone elements (see Table 7-1), so the example text would have to be inside a p.

langusage

A catalog of languages used in the document. It contains one or more language elements, each of which might have an id attribute on it so that it can be referenced from prod elements. The language element contains character data (see Table 7-2).

revisiondesc

A catalog of changes made to the document, in more or less rigorous form. It contains a mixture of zero or many standalone elements (see Table 7-1); typically, an slist element would be used, with its sitem elements corresponding to individual change descriptions and dates.

Processing Expectations

The various parts of the header are used in creating a title page that follows W3C rules. The content of some elements is used twice or more, while the content of other elements is suppressed from display. Some of the elements (such as publoc) should cause heading text to be generated.

The element name has, in addition to the common attribute, a key attribute, which optionally provides a sort-key string for use in collecting and outputting names mentioned in a document.

The element email has common attributes and a required href attribute.

Rationale

The content model of header has been parameterized so that the metadata can be customized, subsetted, and extended as necessary.

The metadata elements that were in the original DTD were cherry-picked, based on the data found in a survey of typical W3C technical report cover and title pages. Where an element is optional, generally content is required inside it to ensure that it's not abused or accidentally left empty.

The subtitle element was added unilaterally because it seemed like a generally good idea.

The w3c-doctype element should perhaps more properly be an attribute with a small set of enumerated values, if the DTD gets wider use and the types are quantified. So far, the element formulation has stood us in good stead because we began to publish "notes" in addition to "working drafts" and did not need to make any stylesheet changes.

The pubdate contains, in order, day (optional), month, and year elements so that different forms of the date could be published in different locations: "31 December 1999" on the title page and "December 1999" on the cover, for example. The content model of pubdate has been parameterized so that a different form of date information can be supplied if necessary.

The status element originally required the statusp variant of the p element because Dan indicated that HTML-style links should be allowed only where they're appropriate. Because inclusions are not allowed in XML and we wanted this DTD to be XML compliant, the only way to allow status to contain loc was to give it a special subelement where loc is allowed. However, we've since found that it's very difficult to excise all need for HTML-style links in the body of the spec, so we ended up extending p to allow it to contain loc and, in preparation for losing statusp entirely, allowed p inside status. Now, statusp is obsolete and has been removed from the DTD.

---

Section 4 Standalone Element Structures

Following are the standalone element structures ("paragraph-level elements"), which make up the bulk of the content of divisions in a technical report. These structures fall into classes, as follows. (Note that the DTD makes slightly finer distinctions than these, for purposes of managing content models.)

• Paragraphs

• Regular lists

• Special lists

• Notes

• Illustrations

---

4.1. Paragraphs (p)

Following is the sole member of the paragraph class:

Paragraph

Description

The p element is a general-purpose paragraph which can contain regular character data, phrase-level elements, and some nested standalone elements (see Chapter 7).

Attributes

The p element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

This element should be presented as vertically set off from other surrounding elements, and its inline text contents should be wrapped as appropriate to fit in the line size available.

Rationale

Originally, only p was made available, and it contained loc . Dan requested that the loc element not be made generally available, because properly these should only occur in the status section of a technical report, and statusp was therefore created because SGML exceptions, which would have allowed for a clean implemention of the restriction, aren't available in XML-compliant DTDs. However, later all the editors came to the conclusion that it was too restrictive not to allow loc anywhere else, and we added loc to regular paragraphs and p to the status section.

The statusp element was a special version of a paragraph that was created to allow loc (see Section 5.4.2) inside it. A statusp contained a mixture of one or more %statusobj.mix; and/or %statusp.pcd.mix;. However, this element has finally been removed for simplicity, since p can do the job itself.

---

4.2. Regular Lists

The following are the members of the regular list class:

	Unordered list
	Ordered list
	Simple list
	Glossary list

---

4.2.1. Unordered List (ulist) and Ordered List (olist)

Description

The ulist element identifies unordered lists (for example, with items indicated with bullets) and the olist element identifies ordered lists (for example, with items indicated with arabic numbers). Both ulist and olist contain one or more item elements, which identifies a list item. An item contains one or more standalone elements (see Table 7-1). Thus, a list item intended to contain a simple text string must first contain a paragraph.

Attributes

The ulist, olist, and item elements have two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, the ulist and olist elements have one unique attribute:

spacing

Specifies the vertical spacing between the list items. Use "normal" to get normal vertical spacing for items; use "compact" to get less spacing. The default is dependent on the stylesheet.

Processing Expectations

List style and formatting are not strictly dictated. An unordered list at the top level (not nested in another unordered list) should generate a bullet for each item. A nested unordered list should typically generate a distinct bullet (e.g., unfilled vs. filled). An ordered list at the top level (not nested in another ordered list) should generate sequenced numbers for its item. A nested ordered list should typically generate a distinct numbering style (e.g., lowercase roman vs. arabic).

Rationale

The ulist element was previously list type="bullets". The olist element was previously list type="number". The element type was split out to achieve greater content model control, and the names were chosen for consistency.

---

4.2.2. Simple List (slist)

Description

The slist element identifies a simple list, in which the items are presumed to contain only a small word or phrase. The slist contains one or more sitem elements, which contains character data and phrase-level elements (see Table 7-2). Simple list items are unlike regular list items in that the simple version can't contain standalone elements.

Attributes

The slist and sitem elements have two common attributes (see Section 2.1):

	id
	role

Processing Expectations

List style and formatting are not strictly dictated. Typically, simple list items are each on their own line, with no bullet or other explicit enumeration.

Rationale

The slist element was previously list type="simple". The element type was split out to achieve greater content model control, and the name was chosen for consistency.

---

4.2.3. Glossary List (glist)

Description

The glist element identifies a glossary list, in which terms or keywords are given a definition. The glist element contains one or more gitem elements. The gitem element is a pair of label and def. A label contains character data and phrase-level elements (see Table 7-2), and a def contains standalone elements (see Table 7-1)

Attributes

The glist, gitem, label, and def elements have two common attributes (see Section 2.1):

	id
	role

Processing Expectations

List style and formatting are not strictly dictated. Typically, glossary list items are formatted as classic hanging-indent or two-column definition lists.

Rationale

The gitem element is a container for paired items in glist elements. A container wasn't previously available; this should make formatting and other processing (such as sorting) easier.

The def element was previously the item element used in a "paired" context. It's easier to process these two uses of "items" if they have distinct element types.

The glist element was previously list type="gloss". The element type was split out to achieve greater content model control, and the name was chosen for consistency.

---

4.3. Special Lists

The following are the members of the special list class:

	Bibliography list
	Organization list

These elements are available in divisions and %obj.mix; content, but are not available inside (for example) paragraphs.

---

4.3.1. Bibliography List (blist)

Description

The blist element identifies a bibliography list. It contains one or more bibl elements, each of which optionally functions as a hypertext reference to the referred-to resource through its href attribute.

The bibl element contains character data and phrase-level elements (see Table 7-2). Its content model does not constrain authors to the use of a particular bibliographic format.

Attributes

The blist and bibl elements have two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, the bibl element has the following semi-common attributes:

	key (see Section 2.2.1)
	href (see Section 2.2.4)

Processing Expectations

List style and formatting are not strictly dictated. Typically, bibliography list items are formatted on their own line, and may use a definition list format by putting the value of the key attribute as the "term."

Rationale

This was previously the listbibl element. The name was changed for consistency.

---

4.3.2. Organization List (orglist)

Description

The orglist element identifies an organization list (for example, a list of Working Group or Interest Group members). It contains one or more member elements. A member contains, in order, name, an optional affiliation, and an optional role.

The name, affiliation, and role elements contain character data (see Table 7-2).

Attributes

The orglist, member, affiliation, role, and name elements have two common attributes (see Section 2.1):

	id
	role

The name element also has the following semi-common attribute:

key (see Section 2.2.1)

Processing Expectations

List style and formatting are not strictly dictated. Typically, organization list items are formatted as a "textual list," wrapped in the content of a paragraph with items and their constituent parts separated by appropriate punctuation.

Rationale

The orglist element was previously the wglist element. The member element was previously the wgm element. The names were changed for consistency and clarity.

---

4.4. Notes

The following are the members of the note class:

	Regular note
	Issue
	Well-formedness constraint note
	Validity constraint note
	Generic constraint note

---

4.4.1. Regular Note (note)

Description

The note element is for admonitions to readers. It contains one or more standalone elements (see Table 7-1).

Attributes

The note element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

Although this element type was originally note place="inline", it was never used in its inline form as far as we can tell; plain notes should be formatted as vertically set-off content with some kind of generated "Note" heading.

Rationale

This was previously note place="inline". The element was split out for greater content model and linking control. We don't expect that notes other than "constraint notes" will be used very often.

---

4.4.2. Issue (issue)

Description

The issue element is for the text of outstanding issues related to the technical report. It contains one or more standalone elements (see Table 7-1).

Attributes

The issue element has two common attributes (see Section 2.1):

	id (required)
	role

Processing Expectations

Issues should be formatted as vertically set-off content with some kind of generated "Issue" heading and a number that identifies the issue uniquely. It is expected that an xref element referring to an issue will refer to it by its issue number, possibly along with its page number (depending on the output media).

Rationale

James added this element for his own purposes in working on XSL, and it seems like a generally good idea. (Note that the processing expectations are somewhat of a guess.)

---

4.4.3. Constraint Notes (wfcnote, vcnote, and constraintnote)

Description

The wfcnote element identifies a well-formedness constraint note and the vcnote element identifies a validity constraint note. The constraintnote element identifies a generic constraint note. All three contain, in order, a head followed by one or more standalone elements (see Table 7-1).

All three elements must each have an id attribute specified so that it can be pointed to from a wfc, vc, or constraint element, respectively, in a production (see Section 4.5.3).

Attributes

The wfcnote, vcnote, and constraintnote elements have two common attributes (see Section 2.1):

	id (required)
	role

In addition, the constraintnote element has a unique attribute, type, which the author must fill in to indicate the type of constraint being described.

Processing Expectations

These note elements should be displayed vertically set off, with a generated heading something like "Well-Formedness Constraint" or "Validity Constraint" followed by the specific head provided. The specific head should also be reproduced as part of the display of the related wfc, vc, or constraint elements. The type attribute on constraintnoteshould be used to trigger the appropriate generated heading and to contribute to the appearance of the related constraint elements.

Rationale

These elements now require an ID so that a constraint element can link to a constraint note element from inside prod. There is no point having a note if there is not at least one corresponding constraint in a production pointing to it.

The two specific elements were previously note type="wf-check" and note type="v-check". The elements were split out for greater content model and linking control.

The generic constraint note element was created because we foresaw a need for additional kinds of constraints when the Namespaces in XML draft was written. (It invented "namespace constraints.") In order to avoid constantly needing to update the DTD to add new constraint types, we chose this solution. Because of the importance of well-formedness and validity constraints to base XML, these specialized types were retained.

---

4.5. Illustrations

The following are the members of the illustration class:

	Example
	Graphic
	Code scrap
	HTML-style table
	IDL definitions

---

4.5.1. Example (eg)

Description

The eg element identifies technical examples. It contains character data and phrase-level elements (see Table 7-2).

Attributes

The eg element has two common attributes (see Section 2.1):

	id
	role

It also has an xml:space attribute with a #FIXED value of "preserve" to indicate that all white space inside the example should be retained by applications.

Processing Expectations

The element should be displayed as vertically set off (even if it appears inside a paragraph) and be given a monospaced font to ensure that characters and white space inside the example line up correctly.

Rationale

We expanded its content a bit from just #PCDATA, so that it can contain footnote and highlighting markup if necessary.

---

4.5.2. Graphic (graphic)

Description

The graphic element is used to reference external graphic files. The graphic data must reside at the location pointed to using the source attribute. The graphic element is declared EMPTY.

Attributes

The graphic element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, the graphic element has the following unique attributes:

source

A required hypertext reference pointing to the graphic data content to be displayed. Other related attributes are also present. See Section 2.2.4 for more information.

alt

An optional alternate string to display if the graphic data cannot be displayed or viewed.

Processing Expectations

The data content pointed to by the source attribute of the graphic element should be presented in place. The values for the XLink behavior attributes show and actuate are fixed to be "embed" and "auto", respectively.

Rationale

The graphic element is done as simply as possible for the moment, because we anticipate the need for graphics (particularly in the XLink and/or XPointer specifications), but none of the specifications have any yet. There seems to be no need for a formal figure with a caption or head, nor for an additional layer of container element to allow for the later addition of graphic metadata. XLink is the obvious mechanism for pointing to the graphic data content.

---

4.5.3. Code Scrap (scrap)

Description

The scrap element identifies code scrap containing language productions. It contains, in order, a head element containing character data, followed by either a bnf element or one or more prod elements or one or more prodgroup elements.

The main element for structuring productions is prod. It contains, in order, an lhs (left-hand side) element identifying the nonterminal that is being defined, followed by one or more groups of rhs (right-hand side fragments) and an optional mixture consisting of com (commentary on the production), wfc (indications of well-formedness constraints), vc (indications of validity constraints), and constraint (generic indications of language constraints). It has a required id attribute so that specref cross-references (see Section 5.4.3) and nt mentions of nonterminals (see Section 5.5.3) can link to it.

The prodgroup element groups productions within a single scrap.

The bnf (Backus-Naur Format) element is for "raw," unformatted productions without internal markup. It contains the same mixture of character data and phrase-level elements as eg does (see Table 7-2) .

The wfc, vc, and constraint elements are empty. These indications of constraints must each use their required def attribute to link to an actual wfcnote, vcnote, or constraintnote element that defines it.

Attributes

The scrap, head, bnf, prod, prodgroup, lhs, rhs, com, nt, xnt, wfc, vc, and constraint elements all have two common attributes (see Section 2.1):

	id (an attribute value is required for prod)
	role

In addition to the common attributes, the wfc, vc, and constraint elements have the following semi-common attribute:

def (required; see Section 2.2.2).

In addition to the common attributes, the scrap element has one unique attribute:

lang

An optional IDREF link to a description of the language used, found in a language element in the header (see Section 3.2).

In addition to the common attributes, the prodgroup element has several unique attributes:

pcwn

Presentational attributes to control the width of the "pseudo-table" columns used to output groups of productions. The first column is pcw1. It can contain up to four more columns, down to pcw5. Values are optional to supply.

Processing Expectations

Each scrap is expected to be displayed vertically set off, with its head used as the label for the whole scrap. Each production should be numbered, and in some presentations, it may be appropriate to produce a "table of productions" at the front that lists the scrap heads, production numbers, and the nonterminals (the content of the lhs) they define. The style of production we have been using involves the generated output of a ::= LHS/RHS equivalence separator. Comments (com) are typically displayed between BNF comment delimiters to the right of each RHS fragment, and possibly italicized. Each RHS fragment is displayed on a separate line. The wfc, vc, and constraint elements should generate in place either "WFC:" or "VC:" or text corresponding to the linked constraintnote element's type attribute, followed by the head of the note they link to.

Rationale

We considered several different "depths" of production markup model, and settled on the current model as the best balance of functionality and presentational control. Modeling EBNF exactly would have required a very heavy markup burden, which most of the editors were not willing to live with, as well as a presenting a difficult formatting challenge, so we compromised by having (for example) several rhs elements per lhs to correspond to each display line.

The prodgroup element and its attributes were added to solve a thorny formatting problem involving the output of tables.

In general, the design here shows very clearly the tension between the design principles of presentation independence and efficient W3C document production.

---

4.5.4. HTML-Style Table (table)

Description

The table element is a full HTML Version 4.0-style table.

Note that the implementation of HTML 4.0 tables in the XMLspec DTD is a new one, with different parameterization, fewer comments, changes to make the DTD fragment compatible with XML, and slight changes to the model. Following are the significant changes made:

• The names of the table and table body elements were changed back from htable and htbody to table and tbody.

• The common attributes were added to all the table elements (see Section 2.1):

  	id
  	role

• All the markup names (element types, attribute names, attribute values, and so on) were made lowercase, to help in manual input since XML is case sensitive.

• The content mixture used for paragraphs was also used for the content of the th and td elements (see Table 7-1 and Table 7-2).

• The full-SGML OMITTAG flags were removed.

• Uses of the full-SGML NUMBER attribute type were changed to NMTOKEN.

• The HTML common, reserved, and datapagesize attributes were removed.

For a full description of the features of HTML 4.0 tables that have been retained in XMLspec, see http://www.w3.org/TR/REC-html40, which is the normative reference for table structure and processing expectations.

Note: The Version 4.0 model removes some attribute defaults that were in force in the simplified 3.2 model used previously. In general, if you want a particular value, make sure to set it yourself.

Rationale

At first, the DTD offered only SGML Open Exchange tables, for which DSSSL formatting support already existed. However, HTML is the primary output for W3C documents, and HTML table formatting was written in DSSSL, so we added the HTML table model as well. More recently, we removed the SGML Open model because only the HTML model was actually being used.

We can easily add the SGML Open table model again if it is ever needed.

Most recently, we switched from an extremely simple HTML-style table model to full HTML 4.0 tables on request from the DOM group. This was to avoid unnecessary transformations in converting to HTML and to allow authors to take full advantage of the geometrical table capabilities that HTML 4.0 offers.

---

4.5.5. IDL Definitions (definitions)

The definitions element structure was contributed by the W3C DOM Working Group. No detailed descriptions, processing expectations, or design rationales have been supplied. This section offers only a structural description.

Note: This model may change in backwards-incompatible ways in the future, to account for the manner in which the markup is actually being used by the DOM group. Use this model with caution.

Following are the IDL element classes. Every class entity has the naming scheme %name.class;, and has an empty %local.name.class; entity in it for customization purposes.

• Descriptive elements (%idl-desc.class;)

  	Paragraph (p)
  	Note (note)

• Type definition elements (%idl-tdef.class;)

  	typedef
  	constant
  	exception
  	reference
  	group

• Module/interface elements (%idl-mod.class;)

  	module
  	interface

• Struct elements (%idl-struct.class;)

  	struct
  	enum
  	sequence
  	union
  	typename

• Method/attribute elements (%idl-meth.class;)

  	method
  	attribute

Table 4-1 shows the element mixtures built up out of the IDL-related elements.

The model for definitions is as follows.

The models for group, interface, module, reference, constant, and exception are as follows.

The model for typedef and its contents is as follows.

The models for method and attribute are as follows.

---

Section 5 Phrase-Level Structures

Following are the phrase-level element structures ("inline-level elements"), which are typically used along with character data. These structures fall into classes, as follows. (Note that the DTD makes slightly finer distinctions than these, for purposes of managing content models.)

• Annotations

• Terms and definitions

• Emphasized text

• References

• Technical

• Editorial note

---

5.1. Annotations (footnote)

The footnote element is the only member of the annotation class.

Description

The footnote element serves as both a marker for the location of the footnote callout and a container for the footnote content. It contains one or more elements in the %obj.mix; mixture.

Attributes

The footnote element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

For print, the location of the footnote element should be given a generated superscripted number or symbol that serves as a callout, and the footnote content should be presented along with the callout at the bottom of the page. In online presentation, the footnote could be presented as a pop-up dialog box keyed to an icon placed at the location of the footnote element.

---

5.2. Terms and Definitions

The following are the members of the term/definition class:

	Defined term
	Term definition

---

5.2.1. Defined Term (term)

Description

The term element identifies a term being defined in text. It contains character data (see Table 7-2). It is mostly used as a substructure of termdef, though it may occasionally be used outside of a termdef context for an "informally" defined term. For information on cross-referencing a term, see Section 5.4.4 and Section 5.4.7.

Attributes

The term element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

This element should be given some sort of typographical emphasis, for example italics.

Rationale

This element exists mostly to allow control of the typographical emphasis, since the term attribute on termdef does the work of supplying a "canonical" form of the term for use in generating definitions. If the canonical term and the term as it appears in text are identical, there is some slight redundancy, but the overhead of using the canonical term in the flow of text (or modifying it if it's inappropriately pluralized or capitalized) isn't worth it.

---

5.2.2. Term Definition (termdef)

Description

The element termdef contains a term definition embedded in text. It contains a mixture of character data and phrase-level elements (see Table 7-2), including somewhere within it a mention of the term being defined (in a term element). Note that because the termdef element has mixed content, the presence of term within it can't be guaranteed by means of a validating XML processor. However, there is an editorial expectation that term will be present. (See issue 7 in Section 1.4.)

Attributes

The termdef element has two common attributes (see Section 2.1). It must have an id attribute so that it can be linked to from termref elements ( Section 5.4.7).

	id (required)
	role

In addition to the common attributes, termdef has one unique attribute:

term

The canonical form of the term or phrase being defined must appear in this attribute, even if the term or phrase also appears in the element content in identical form (in the term element).

Processing Expectations

While no special behavior or formatting is required, there are some opportunities for clever definition handling. For example, the terms and definitions could be assembled into a generated glossary, or definitions could be given some sort of boxing or generated-text boundaries in running text.

Rationale

Because we wanted to continue to allow definitions in running text, the mixed-content solution was the only reasonable choice even though it means that the DTD can't ensure that proper markup has been used.

---

5.3. Emphasized Text

The following are the members of the emphasized text class:

	Emphasized text
	Quote

---

5.3.1. Emphasized Text (emph)

Description

The emph element identifies text that should be given extra rhetorical emphasis. It contains character data (see Table 7-2).

Attributes

The emph element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

The content of the emph element should be given typographical emphasis, typically italic or boldface.

Rationale

If not abused, this element can be useful, and its presence probably forestalls abuse of other elements that happen to produce typographical emphasis. Since it is expected to contain only a word or two of natural language, it need only contain #PCDATA.

---

5.3.2. Quote (quote)

Description

The quote element identifies text that needs "scare quotes." It contains a mixture of character data and the same phrase-level elements that are allowed in paragraphs (see Table 7-2).

Attributes

The quote element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

The content of the element should be presented with quotation marks around it, as appropriate for the language of the text in the document.

Rationale

This element was added to help manage the process of adding casual quotes. In an XML-aware environment, it is often easier to manage content in containers rather than as discrete symbols (for example, a left quote, then some text, then a right quote).

---

5.4. References

The following are the members of the reference class:

	Bibliography reference
	URI reference
	Specification reference
	Term reference
	Title reference
	External specification reference
	External term definition reference

The nt (nonterminal reference) and xnt (external nonterminal reference) elements could also count as reference elements; however, they are discussed as members of the technical class (see Section 5.5.4).

---

5.4.1. Bibliography Reference (bibref)

Description

The bibref element identifies a reference to a bibliography entry in a blist element in the current document. It is declared to be empty. It links to the bibl element that describes the resource; in other words, this is only an indirect reference to the resource.

Attributes

The bibref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, the bibref element has the following semi-common attribute:

ref (required; see Section 2.2.3)

Processing Expectations

This element should generate, in square brackets, the value of the key attribute on the referenced bibl element (see Section 4.3.1).

Rationale

This element is allowed in a wide variety of places because (as noted in issue 4 in Section 1.4) the proper way to refer to any resource is by means of a bibliography reference. It is empty so that the proper reference text can be generated automatically.

---

5.4.2. URI Reference (loc)

Description

The loc element identifies a World Wide Web resource by its URI and functions as a hypertext link to a resource, essentially the same as an HTML A element does. (Ideally, the content of the loc element will also mention the URI , so that readers of the printed version will be able to locate the resource.) It contains character data (see Table 7-2).

Typically, loc elements should be avoided anywhere in a specification in favor of bibref. See issue 4 in Section 1.4 for more information.

Attributes

The loc element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it has the following semi-common attribute:

href (required; see Section 2.2.4)

Processing Expectations

In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource. In print presentation, there may or may not be typographical distinction.

Rationale

This element was added early on, before W3C policy seemed to have solidified on the issue. The element may now be obsolescent.

Its name was chosen before the decision to use URIs instead of just URLs in XML. Such a reference might specify a physical location, a universal identifier for the resource, or something partway between the two.

---

5.4.3. Specification Reference (specref)

Description

The specref element identifies a cross-reference to another location in the current specification. It is declared to be empty. It is intended to be used to link to a div (division), an item in an olist (numbered list item), a prod (language production), or an issue (specification issue) in the current specification.

Attributes

The specref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

ref (required; see Section 2.2.3)

Processing Expectations

The specref element should generate a unique pattern of text depending on the cross-reference target:

• For div, it should generate "Section sec-num.subsec-num, Title of the Section".

• For item in olist, it should generate "item-number".

• For prod, it should generate "[prod-number]".

• For issue, it should generate "Issue issue-number".

In electronic presentation, the generated text should be "hot" to allow a user to traverse the link to the referenced resource.

Rationale

Having this element be empty ensures that consistent and correct cross-reference text will be generated.

The original reason that this element is separate from xspecref is that this one uses the ID/IDREF method of linking and xspecref uses the XLink/XPointer method. However, even if this element later switches to XLink, it may still be useful to have two separate elements, since this one does not document a cross-document dependency and xspecref does.

---

5.4.4. Term Reference (termref)

Description

The termref element identifies a mention of a term that is defined elsewhere in the current specification; the mention also serves as a reference to the definition by linking to the termdef element that defines the term (see Section 5.2.1). The termref element contains character data (see Table 7-2).

It is expected that not every mention will be marked up. If a particular term is used with regularity in a single passage or section, it is more reasonable to mark up only the first occurrence of that term within the passage or section.

Attributes

The termref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

def (required; see Section 2.2.2)

Processing Expectations

In electronic presentation, the content of the element should be "hot" to allow a user to traverse the link to the referenced resource. In print presentation, typically it is given typographical distinction (such as italics).

Rationale

This element allows users to easily find the definition of a term being used in text.

---

5.4.5. Title Reference (titleref)

Description

The titleref element identifies a citation of the title of another work. A title reference can optionally function as a hypertext link to the resource that has this title. It contains character data (see Table 7-2).

The titleref element is typically expected to be used inside the bibl element, to supply the title of the work being identified in the bibliography entry. Note that both the bibl element and the titleref element can function as a hypertext link to the referenced resource; see issue 5 in Section 1.4.

Attributes

The titleref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

href (see Section 2.2.4)

Processing Expectations

In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource. In all presentations, the title of the work will typically be rendered in italics.

Rationale

It is fairly clear that a means to mark up a reference to a title is appropriate, since at the very least such references are made to look different from their surroundings are aren't just "emphasized text." However, the hypertext function is less clearly needed. See issue 5 in Section 1.4.

---

5.4.6. External Specification Reference (xspecref)

Description

The xspecref element is a reference to all or part of another W3C specification. It must hyperlink to the targeted resource. It contains character data (see Table 7-2).

Attributes

The xspecref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

href (required; see Section 2.2.4)

Processing Expectations

In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource. In print presentation, there may or may not be typographical distinction.

Rationale

The xspecref element was added in response to a need to make hyperlinks to "base" specifications from specifications that properly depend on them. For example, the XML specification develops some concepts that are used in the XLink specification. Since this is more than a simple citation to another resource but rather provides details on the dependency, it seems appropriate to make this different from a regular specref.

The original reason that this element is separate from specref is that specref uses the ID/IDREF method of linking and this element uses the XLink/XPointer method. However, even if specref later switches to XLink, it is still be useful to have two separate elements.

---

5.4.7. External Term Definition Reference (xtermref)

Description

The xtermref element identifies a mention of a term that is defined in another specification; the mention also serves as a reference to the definition by linking to the termdef element in the other specification that defines the term (see Section 5.2.1). It contains character data (see Table 7-2).

Attributes

The xtermref element has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

href (required; see Section 2.2.4)

Processing Expectations

In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource. In print presentation, there may or may not be typographical distinction.

Rationale

The xtermdef element was added in response to a need to make hyperlinks to "base" definitions from specifications that properly depend on these definitions. For example, the XML specification defines some terms that are used in the XLink specification. Since this is more than a simple citation to another resource but rather provides details on the dependency, it seems appropriate to make this different from a regular termdef.

The original reason that this element is separate from termdef is that termdef uses the ID/IDREF method of linking and this element uses the XLink/XPointer method. However, even if termdef later switches to XLink, it is still be useful to have two separate elements.

---

5.5. Technical

The following are the members of the technical class:

	Code fragment
	Keyword
	Nonterminal reference
	External nonterminal reference

---

5.5.1. Code Fragment (code)

Description

The code element contains a code fragment. It contains a mixture of character data and phrase-level elements (see Table 7-2).

This element should be used whenever a code fragment can't be identified more precisely as a keyword or nonterminal. For example, a sample XML start-tag with attribute specifications provided in text might use the code element.

Attributes

The code element has two common attributes (see Section 2.1):

	id
	role

Processing Expectations

The content of the element should be given typographical distinction, typically a monospaced font.

Rationale

This element is useful as the escape hatch for technical content. (Therefore, care should be taken not to abuse it.)

---

5.5.2. Keyword (kw)

Description

The kw element contains a keyword in the language being described in the document. For example, it might be used for describing enumerated attribute value tokens in an XML-based markup language. It contains a mixture of character data and phrase-level elements (see Table 7-2).

Attributes

The kw element contains two common attributes (see Section 2.1):

	id
	role

Processing Expectations

The content of the element should be given typographical distinction, typically a monospaced font. Depending on the presentation, other processing, such as indexing each keyword in a paper index as "name keyword", might be appropriate.

Rationale

It is useful to mark up keywords separately from random strings of code because it can be desirable to index the keywords specially.

---

5.5.3. Nonterminal Reference (nt)

Description

The nt element is a mention of a nonterminal symbol that appears in a language production in the current specification. It must link to the production that defines the nonterminal. It contains character data (see Table 7-2).

Attributes

The element nt has two common attributes (see Section 2.1):

	id
	role

In addition to the common attributes, it also has the following semi-common attribute:

def (required; see Section 2.2.2)

Processing Expectations

The content of the element should be given typographical distinction, typically a monospaced font. Depending on the presentation, other processing, such as indexing each mention in a paper index, might be appropriate. In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource.

Rationale

Since nonterminals are often the basis of the formal definition of a language in a W3C specification, it makes sense to treat them specially. Mentions of nonterminals are required to link to the relevant production not just as an aid to the reader, but also to provide another check that every nonterminal has its own production.

---

5.5.4. External Nonterminal Reference (xnt)

Description

The xnt element identifies a mention of a nonterminal symbol whose production appears in another specification; the mention also serves as a reference to the production by linking to the prod element in the other specification that defines the term (see Section 4.5.3). It contains character data (see Table 7-2).

Attributes

The xnt element contains two common attributes (see Section 2.1):

	id
	role

In addition, it contains the following semi-common element:

href (required; see Section 2.2.4)

Processing Expectations

The content of the element should be given typographical distinction, typically a monospaced font. Depending on the presentation, other processing, such as indexing each mention in a paper index, might be appropriate. In electronic presentation, the content of this element should be "hot" to allow a user to traverse the link to the referenced resource.

Rationale

Since nonterminals are often the basis of the formal definition of a language in a W3C specification, it makes sense to treat them specially. Mentions of nonterminals are required to link to the relevant production not just as an aid to the reader, but also to provide another check that every nonterminal has its own production. The xnt element was added in response to a need to make hyperlinks to "base" productions from specifications that properly depend on these productions. For example, the XML specification defines some nonterminals that are used in the XLink specification. Since this is more than a simple citation to another resource but rather provides details on the dependency, it seems appropriate to make this different from a regular nt.

The original reason that this element is separate from nt is that nt uses the ID/IDREF method of linking and this element uses the XLink/XPointer method. However, even if nt later switches to XLink, it is still be useful to have two separate elements.

---

5.6. Editorial Notes (ednote)

The ednote element is the only member of the editorial note class.

Description

The ednote element identifies commentary passed between editors and authors of a document. It contains an optional name element (the name of the person making the commentary), followed by an optional date element (the date the commentary was made), followed by an edtext element (the substance of the commentary). The date and edtext elements contain character data (see Table 7-2). The name element is discussed along with the specification header element, in Section 3.2.

Attributes

The ednote element contains two common attributes (see Section 2.1):

	id
	role

Processing Expectations

The content of this element should be suppressed in all "official" versions of a document, but in draft versions, the various parts of its content could be displayed and even given prominence.

Rationale

XML comments aren't usually sufficient for communications between authors because, in output versions of a document, comments don't appear. Having an element makes the communications more manageable and trackable, while not requiring a whole workflow system. The name and date "metadata" were made elements simply for convenience of input; in many XML-aware environments, it can be easiser to insert elements than attributes, and hopefully this will encourage their use.

The content of edtext need not be more complicated than #PCDATA because the note doesn't need to contribute to the "real" content of the document.

---

Section 6 Making Connections

---

6.1. Linking Relationships

The following table shows the expected linking relationships among pieces of information using this DTD. See Section 1.4 for information on outstanding issues related to linking.

---

6.2. Characters and Symbols

The following table summarizes the character and symbol entities defined in the DTD.

---

Section 7 Element Classes and Mixtures

Following are the general element classes and mixtures used in this DTD. (See Section 4.5.5 for IDL-specific classes and mixtures.)

---

7.1. Standalone Element Classes and Mixtures

Following are the precise standalone element classes. Every class entity has the naming scheme %name.class;, and has an empty %local.name.class; entity in it for customization purposes.

• Paragraphs (%p.class;)

  Paragraph (p)

• Regular lists (%list.class;)

  	Unordered list (ulist)
  	Ordered list (olist)
  	Simple list (slist)
  	Glossary list (glist)

• Special lists (%speclist.class;)

  	Bibliography list (blist)
  	Organization list (orglist)

• Notes (%note.class;)

  	Regular note (note)
  	Issue (issue)
  	Well-formedness constraint note (wfcnote)
  	Validity constraint note (vcnote)
  	Generic constraint note (constraintnote)

• Illustrations (%illus.class;)

  	Example (eg)
  	Graphic (graphic)
  	Code scrap (scrap)
  	HTML-style table (table)

Table 7-1 shows the element mixtures built up out of standalone elements. Note that some of the standalone mixtures also include the phrase-level element ednote.

---

7.2. Phrase-Level Element Mixtures

Following are the precise phrase-level element classes. Every class entity has the naming scheme %name.class;, and has an empty %local.name.class; entity in it for customization purposes.

• Annotations (%annot.class;)

  Footnote (footnote)

• Term/definition (%termdef.class;)

  	Term definition (termdef)
  	Defined term (term)

• Emphasis (%emph.class;)

  	Emphasized text (emph)
  	Quote (quote)

• References (%ref.class;)

  	Bibliography reference bibref
  	Specification reference specref
  	Term reference termref
  	Title reference titleref
  	External specification reference xspecref
  	External term definition reference xtermref

• Web location references (%loc.class;)

  Web location reference (loc)

• Technical (%tech.class;)

  	Keyword (kw)
  	Nonterminal reference (nt)
  	External nonterminal reference (xnt)
  	Code fragment (code)

• Editorial note (%ednote.class;)

  Editorial note (ednote)

Table 7-2 shows the element mixtures built up out of "character data" (here standing for #PCDATA, entity references, and character references) and phrase-level elements. Note that many phrase-level elements themselves allow phrase-level subelements; these elements are represented on both axes.

---

Section 8 XMLspec DTD Listing

<!-- ............................................................... -->
<!-- XML specification DTD ......................................... -->
<!-- ............................................................... -->

<!--
TYPICAL INVOCATION:
#  <!DOCTYPE spec PUBLIC
#       "-//W3C//DTD Specification::19980910//EN"
#       "http://www.w3.org/XML/1998/06/xmlspec-19980910.dtd">

PURPOSE:
  This DTD was developed for use with the XML family of W3C
  specifications.  It is an XML-compliant DTD based in part on the TEI
  Lite and Sweb DTDs.

DEPENDENCIES:
  None.

CHANGE HISTORY:
  The list of changes is at the end of the DTD.

  For all details, see the design report at:

#   <http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm>

  The "typical invocation" FPI always gets updated to reflect the date
  of the most recent changes.

  Search this file for "#" in the first column to see change history
  comments.

MAINTAINER:
  Eve Maler
  ArborText Inc.
  elm@arbortext.com
  voice: +1 781 270 5750
  fax:   +1 781 273 3760
-->

<!-- ............................................................... -->
<!-- Entities for characters and symbols ........................... -->
<!-- ............................................................... -->

<!--
#1998-03-10: maler: Added &ldquo; and &rdquo;.
#                   Used 8879:1986-compatible decimal character
#                   references.
#                   Merged charent.mod file back into main file.
#1998-05-14: maler: Fixed ldquo and rdquo.  Gave mdash a real number.
-->

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">
<!ENTITY nbsp   "&#160;">
<!ENTITY mdash  "&#x2014;">
<!ENTITY ldquo  "&#x201C;">
<!ENTITY rdquo  "&#x201D;">

<!-- ............................................................... -->
<!-- Entities for classes of standalone elements ................... -->
<!-- ............................................................... -->

<!--
#1997-10-16: maler: Added table to %illus.class;.
#1997-11-28: maler: Added htable to %illus.class;.
#1997-12-29: maler: IGNOREd table.
#1998-03-10: maler: Removed SGML Open-specific %illus.class;.
#                   Added "local" entities for customization.
#1998-05-14: maler: Added issue to %note.class;.
#                   Removed %[local.]statusp.class;.
#1998-05-21: maler: Added constraintnote to %note.class;.
#1998-08-22: maler: Changed htable to table in %illus.class;.
#                   Added definitions to %illus.class;.
-->

<!ENTITY % local.p.class        "">
<!ENTITY % p.class              "p
                                %local.p.class;">

<!ENTITY % local.list.class     "">
<!ENTITY % list.class           "ulist|olist|slist|glist
                                %local.list.class;">

<!ENTITY % local.speclist.class "">
<!ENTITY % speclist.class       "orglist|blist
                                %local.speclist.class;">

<!ENTITY % local.note.class     "">
<!ENTITY % note.class           "note|issue|wfcnote|vcnote
                                |constraintnote %local.note.class;">

<!ENTITY % local.illus.class    "">
<!ENTITY % illus.class          "eg|graphic|scrap|table|definitions
                                %local.illus.class;">

<!-- ............................................................... -->
<!-- Entities for classes of phrase-level elements ................. -->
<!-- ............................................................... -->

<!--
#1997-12-29: maler: Added xspecref to %ref.class;.
#1998-03-10: maler: Added %ednote.class;.
#                   Added "local" entities for customization.
-->

<!ENTITY % local.annot.class    "">
<!ENTITY % annot.class          "footnote
                                %local.annot.class;">

<!ENTITY % local.termdef.class  "">
<!ENTITY % termdef.class        "termdef|term
                                %local.termdef.class;">

<!ENTITY % local.emph.class     "">
<!ENTITY % emph.class           "emph|quote
                                %local.emph.class;">

<!ENTITY % local.ref.class      "">
<!ENTITY % ref.class            "bibref|specref|termref|titleref
                                |xspecref|xtermref
                                %local.ref.class;">

<!ENTITY % local.loc.class      "">
<!ENTITY % loc.class            "loc
                                %local.loc.class;">

<!ENTITY % local.tech.class     "">
<!ENTITY % tech.class           "kw|nt|xnt|code
                                %local.tech.class;">

<!ENTITY % local.ednote.class   "">
<!ENTITY % ednote.class         "ednote
                                %local.ednote.class;">

<!-- ............................................................... -->
<!-- Entities for mixtures of standalone elements .................. -->
<!-- ............................................................... -->

<!--
#1997-09-30: maler: Created %p.mix; to eliminate p from self.
#1997-09-30: maler: Added %speclist.class; to %obj.mix; and %p.mix;.
#1997-09-30: maler: Added %note.class; to %obj.mix; and %p.mix;.
#1997-10-16: maler: Created %entry.mix;.  Note that some elements
#                   left out here are still allowed in termdef,
#                   which entry can contain through %p.pcd.mix;.
#1997-11-28: maler: Added %p.class; to %statusobj.mix;.
#1998-03-10: maler: Added %ednote.class; to all mixtures, except
#                   %p.mix; and %statusobj.mix;, because paragraphs
#                   and status paragraphs will contain ednote
#                   through %p.pcd.mix;.
#1998-03-23: maler: Added %termdef.mix; (broken out from
#                    %termdef.pcd.mix;).
#1998-05-14: maler: Removed %statusobj.mix; and all mentions of
#                   %statusp.mix;.
-->

<!ENTITY % div.mix
        "%p.class;|%list.class;|%speclist.class;|%note.class;
        |%illus.class;|%ednote.class;">
<!ENTITY % obj.mix
        "%p.class;|%list.class;|%speclist.class;|%note.class;
        |%illus.class;|%ednote.class;">
<!ENTITY % p.mix
        "%list.class;|%speclist.class;|%note.class;|%illus.class;">
<!ENTITY % entry.mix
        "%list.class;|note|eg|graphic|%ednote.class;">
<!ENTITY % hdr.mix
        "%p.class;|%list.class;|%ednote.class;">
<!ENTITY % termdef.mix
        "%note.class;|%illus.class;">

<!-- ............................................................... -->
<!-- Entities for mixtures of #PCDATA and phrase-level elements .... -->
<!-- ............................................................... -->

<!--    Note that %termdef.pcd.mix contains %note.class;
        and %illus.class;, considered standalone elements. -->

<!--
#1997-09-30: maler: Added scrap and %note.class; to %termdef.pcd.mix;.
#1997-11-28: maler: Added %loc.class; to %p.pcd.mix;.
#1998-03-10: maler: Added %ednote.class; to all mixtures.
#1998-03-23: maler: Moved some %termdef.pcd.mix; stuff out to
#                   %termdef.mix;.
#1998-05-14: maler: Removed %statusp.pcd.mix;.
#1998-05-21: maler: Added constraint element to %eg.pcd.mix;.
-->

<!ENTITY % p.pcd.mix
        "#PCDATA|%annot.class;|%termdef.class;|%emph.class;
        |%ref.class;|%tech.class;|%loc.class;|%ednote.class;">
<!ENTITY % head.pcd.mix
        "#PCDATA|%annot.class;|%emph.class;|%tech.class;
        |%ednote.class;">
<!ENTITY % label.pcd.mix
        "#PCDATA|%annot.class;|%termdef.class;|%emph.class;
        |%tech.class;|%ednote.class;">
<!ENTITY % eg.pcd.mix
        "#PCDATA|%annot.class;|%emph.class;|%ednote.class;|constraint">
<!ENTITY % termdef.pcd.mix
        "#PCDATA|term|%emph.class;|%ref.class;|%tech.class;
        |%ednote.class;">
<!ENTITY % bibl.pcd.mix
        "#PCDATA|%emph.class;|%ref.class;|%loc.class;|%ednote.class;">
<!ENTITY % tech.pcd.mix
        "#PCDATA|%ednote.class;">
<!ENTITY % loc.pcd.mix
        "#PCDATA|%loc.class;|%ednote.class;">

<!-- ............................................................... -->
<!-- Entities for customizable content models ...................... -->
<!-- ............................................................... -->

<!--
#1998-03-10: maler: Added customization entities.
#1998-05-14: maler: Allowed prevlocs and latestloc in either order.
-->

<!ENTITY % spec.mdl
        "header, front?, body, back?">

<!ENTITY % header.mdl
        "title, subtitle?, version, w3c-designation, w3c-doctype,
        pubdate, notice*, publoc, ((prevlocs, latestloc?) |
        (latestloc, prevlocs?))?, authlist, status, abstract,
        pubstmt?, sourcedesc?, langusage, revisiondesc">

<!ENTITY % pubdate.mdl
        "day?, month, year">

<!-- ............................................................... -->
<!-- Entities for common attributes ................................ -->
<!-- ............................................................... -->

<!--    key attribute:
        Optionally provides a sorting or indexing key, for cases when
        the element content is inappropriate for this purpose. -->
<!ENTITY % key.att
        'key                    CDATA           #IMPLIED'>

<!--    def attribute:
        Points to the element where the relevant definition can be
        found, using the IDREF mechanism.  %def.att; is for optional
        def attributes, and %def-req.att; is for required def
        attributes. -->
<!ENTITY % def.att
        'def                    IDREF           #IMPLIED'>
<!ENTITY % def-req.att
        'def                    IDREF           #REQUIRED'>

<!--    ref attribute:
        Points to the element where more information can be found,
        using the IDREF mechanism.  %ref.att; is for optional
        ref attributes, and %ref-req.att; is for required ref
        attributes. -->
<!ENTITY % ref.att
        'ref                    IDREF           #IMPLIED'>
<!ENTITY % ref-req.att
        'ref                    IDREF           #REQUIRED'>

<!--
#1998-03-23: maler: Added show and actuate attributes to href.
#                   Added semi-common xml:space attribute.
#1998-08-22: maler: Used new xlink:form and #IMPLIED features.
-->

<!--    HREF and source attributes:
        Points to the element where more information or source data
        can be found, using the URL/XLink simple link mechanism.
        For some purposes, is associated with additional XLink
        attributes. %href.att; is for optional HREF attributes,
        and %href-req.att; is for required HREF attributes.
        %source-req.att; is for the source attribute, which
        is always required.  When HREF is supplied in the href.att
        version, default for xlink:form should be understood to be
        "simple". When HREF is not supplied, xlink:form should be
        understood to be "none". -->
        
<!ENTITY % href.att
        'xlink:form             CDATA           #IMPLIED
        href                    CDATA           #IMPLIED
        show                    CDATA           #FIXED "embed"
        actuate                 CDATA           #FIXED "auto" '>

<!ENTITY % href-req.att
        'xlink:form             CDATA           #FIXED "simple"
        href                    CDATA           #REQUIRED
        show                    CDATA           #FIXED "embed"
        actuate                 CDATA           #FIXED "auto" '>

<!ENTITY % source-req.att
        'xlink:form             CDATA           #FIXED "simple"
        xml:attributes          NMTOKENS        #FIXED "href source"
        source                  CDATA           #REQUIRED
        show                    CDATA           #FIXED "embed"
        actuate                 CDATA           #FIXED "auto" '>

<!--    xml:space attribute:
        Indicates that the element contains white space
        that the formatter or other application should retain,
        as appropriate to its function. -->
<!ENTITY % xmlspace.att
        'xml:space              (default
                                |preserve)      #FIXED "preserve" '>

<!--    Common attributes:
        Every element has an ID attribute (sometimes required,
        but usually optional) for links, and a Role attribute
        for extending the useful life of the DTD by allowing
        authors to make subclasses for any element. %common.att;
        is for common attributes where the ID is optional, and
        %common-idreq.att; is for common attributes where the
        ID is required. -->
<!ENTITY % common.att
        'id                     ID              #IMPLIED
        role                    NMTOKEN         #IMPLIED'>
<!ENTITY % common-idreq.att
        'id                     ID              #REQUIRED
        role                    NMTOKEN         #IMPLIED'>

<!-- ............................................................... -->
<!-- Common elements ............................................... -->
<!-- ............................................................... -->

<!--    head: Title on divisions, productions, and the like -->
<!ELEMENT head (%head.pcd.mix;)*>
<!ATTLIST head %common.att;>

<!-- ............................................................... -->
<!-- Major specification structure ................................. -->
<!-- ............................................................... -->

<!--
#1998-03-10: maler: Made spec content model easily customizable.
-->

<!ELEMENT spec (%spec.mdl;)>
<!ATTLIST spec %common.att;>

<!ELEMENT front (div1+)>
<!ATTLIST front %common.att;>

<!ELEMENT body (div1+)>
<!ATTLIST body %common.att;>

<!--
#1997-09-30: maler: Added inform-div1 to back content.
-->

<!ELEMENT back ((div1+, inform-div1*) | inform-div1+)>
<!ATTLIST back %common.att;>

<!ELEMENT div1 (head, (%div.mix;)*, div2*)>
<!ATTLIST div1 %common.att;>

<!--
#1997-09-30: maler: Added inform-div1 declarations.
-->

<!--    inform-div1: Non-normative division in back matter -->
<!ELEMENT inform-div1 (head, (%div.mix;)*, div2*)>
<!ATTLIST inform-div1 %common.att;>

<!ELEMENT div2 (head, (%div.mix;)*, div3*)>
<!ATTLIST div2 %common.att;>

<!ELEMENT div3 (head, (%div.mix;)*, div4*)>
<!ATTLIST div3 %common.att;>

<!ELEMENT div4 (head, (%div.mix;)*)>
<!ATTLIST div4 %common.att;>

<!-- ............................................................... -->
<!-- Specification header .......................................... -->
<!-- ............................................................... -->

<!--
#1998-03-10: maler: Made header content model easily customizable.
-->

<!ELEMENT header (%header.mdl;)>
<!ATTLIST header %common.att;>

<!--    Example of title: "Extensible Cheese Language (XCL)" -->
<!ELEMENT title (#PCDATA)>
<!ATTLIST title %common.att;>

<!--    Example of subtitle: "A Cheesy Specification" -->
<!ELEMENT subtitle (#PCDATA)>
<!ATTLIST subtitle %common.att;>

<!--    Example of version: "Version 666.0" -->
<!ELEMENT version (#PCDATA)>
<!ATTLIST version %common.att;>

<!--    Example of w3c-designation: "WD-xcl-19991231" -->
<!ELEMENT w3c-designation (#PCDATA)>
<!ATTLIST w3c-designation %common.att;>

<!--    Example of w3c-doctype: "World Wide Web Consortium Working
        Draft" -->
<!ELEMENT w3c-doctype (#PCDATA)>
<!ATTLIST w3c-doctype %common.att;>

<!--
#1998-03-10: maler: Made pubdate content model easily customizable.
-->

<!ELEMENT pubdate (%pubdate.mdl;)>
<!ATTLIST pubdate %common.att;>

<!ELEMENT day (#PCDATA)>
<!ATTLIST day %common.att;>

<!ELEMENT month (#PCDATA)>
<!ATTLIST month %common.att;>

<!ELEMENT year (#PCDATA)>
<!ATTLIST year %common.att;>

<!--    Example of notice: "This draft is for public comment..." -->
<!ELEMENT notice (%hdr.mix;)+>
<!ATTLIST notice %common.att;>

<!ELEMENT publoc (loc+)>
<!ATTLIST publoc %common.att;>

<!ELEMENT prevlocs (loc+)>
<!ATTLIST prevlocs %common.att;>

<!ELEMENT latestloc (loc+)>
<!ATTLIST latestloc %common.att;>

<!--      loc (defined in "Phrase-level elements" below) -->

<!ELEMENT authlist (author+)>
<!ATTLIST authlist %common.att;>

<!--
#1997-09-30: maler: Made affiliation optional.
#1998-03-10: maler: Made email optional.
-->

<!ELEMENT author (name, affiliation?, email?)>
<!ATTLIST author %common.att;>

<!ELEMENT name (#PCDATA)>
<!ATTLIST name
        %common.att;
        %key.att;>

<!ELEMENT affiliation (#PCDATA)>
<!ATTLIST affiliation %common.att;>

<!ELEMENT email (#PCDATA)>
<!--    HREF attribute:
        email functions as a hypertext reference through this
        required attribute.  Typically the reference would use
        the mailto: scheme.  E.g.:

<email href="mailto:elm@arbortext.com">elm@arbortext.com</email>
        -->

<!ATTLIST email
        %common.att;
        %href-req.att;>

<!--
#1998-05-15: maler: Changed status content from %statusobj.mix;
#                   to plain %obj.mix;.  statusp is obsolete.
-->

<!ELEMENT status (%obj.mix;)+>
<!ATTLIST status %common.att;>

<!ELEMENT abstract (%hdr.mix;)*>
<!ATTLIST abstract %common.att;>

<!ELEMENT pubstmt (%hdr.mix;)+>
<!ATTLIST pubstmt %common.att;>

<!ELEMENT sourcedesc (%hdr.mix;)+>
<!ATTLIST sourcedesc %common.att;>

<!ELEMENT langusage (language+)>
<!ATTLIST langusage %common.att;>

<!ELEMENT language (#PCDATA)>
<!ATTLIST language %common.att;>

<!ELEMENT revisiondesc (%hdr.mix;)+>
<!ATTLIST revisiondesc %common.att;>

<!-- ............................................................... -->
<!-- Paragraph ..................................................... -->
<!-- ............................................................... -->

<!--
#1997-09-30: maler: Changed from %obj.mix; to %p.mix;.
#1997-12-29: maler: Changed order of %p.mix; and %p.pcd.mix;
#                   references.
#1997-12-29: maler: Changed order of %statusobj.mix; and
#                   %statusp.pcd.mix; references.
#1998-05-14: maler: Removed statusp declarations.
-->

<!ELEMENT p (%p.pcd.mix;|%p.mix;)*>
<!ATTLIST p %common.att;>

<!-- ............................................................... -->
<!-- Regular lists ................................................. -->
<!-- ............................................................... -->

<!ELEMENT ulist (item+)>
<!--    spacing attribute:
        Use "normal" to get normal vertical spacing for items;
        use "compact" to get less spacing.  The default is dependent
        on the stylesheet. -->
<!ATTLIST ulist
        %common.att;
        spacing         (normal|compact)        #IMPLIED>

<!ELEMENT olist (item+)>
<!--    spacing attribute:
        Use "normal" to get normal vertical spacing for items;
        use "compact" to get less spacing.  The default is dependent
        on the stylesheet. -->
<!ATTLIST olist
        %common.att;
        spacing         (normal|compact)        #IMPLIED>

<!ELEMENT item (%obj.mix;)+>
<!ATTLIST item %common.att;>

<!ELEMENT slist (sitem+)>
<!ATTLIST slist %common.att;>

<!ELEMENT sitem (%p.pcd.mix;)*>
<!ATTLIST sitem %common.att;>

<!ELEMENT glist (gitem+)>
<!ATTLIST glist %common.att;>

<!ELEMENT gitem (label, def)>
<!ATTLIST gitem %common.att;>

<!ELEMENT label (%label.pcd.mix;)*>
<!ATTLIST label %common.att;>

<!ELEMENT def (%obj.mix;)*>
<!ATTLIST def %common.att;>

<!-- ............................................................... -->
<!-- Special lists ................................................. -->
<!-- ............................................................... -->

<!ELEMENT blist (bibl+)>
<!ATTLIST blist %common.att;>

<!ELEMENT bibl (%bibl.pcd.mix;)*>
<!--    HREF attribute:
        bibl optionally functions as a hypertext reference to the
        referred-to resource through this attribute.  E.g.:

        <bibl href="http://www.my.com/doc.htm">My Document</bibl>
        -->
<!ATTLIST bibl
        %common.att;
        %href.att;
        %key.att;>

<!ELEMENT orglist (member+)>
<!ATTLIST orglist %common.att;>

<!--
#1997-09-30: maler: Added optional affiliation.
-->

<!ELEMENT member (name, affiliation?, role?)>
<!ATTLIST member %common.att;>

<!--      name (defined in "Specification header" above) -->
<!--      affiliation (defined in "Specification header" above) -->

<!ELEMENT role (#PCDATA)>
<!ATTLIST role %common.att;>

<!-- ............................................................... -->
<!-- Notes ......................................................... -->
<!-- ............................................................... -->

<!ELEMENT note (%obj.mix;)+>
<!ATTLIST note %common.att;>

<!--
#1998-05-14: maler: Declared issue element.
-->

<!ELEMENT issue (%obj.mix;)+>
<!ATTLIST issue %common-idreq.att;>

<!ELEMENT wfcnote (head, (%obj.mix;)+)>
<!--    ID attribute:
        wfcnote must have an ID so that it can be pointed to
        from a wfc element in a production. -->
<!ATTLIST wfcnote
        %common-idreq.att;>

<!ELEMENT vcnote (head, (%obj.mix;)+)>
<!--    ID attribute:
        vcnote must have an ID so that it can be pointed to
        from a vc element in a production. -->
<!ATTLIST vcnote
        %common-idreq.att;>

<!--
#1998-05-21: maler: Declared generic constraintnote element.
-->

<!ELEMENT constraintnote (head, (%obj.mix;)+)>
<!--    ID attribute:
        cnote must have an ID so that it can be pointed to
        from a constraint element in a production. -->
<!--    type attribute:
        cnote must have a type value keyword so that it can be
        correctly characterized in the specification. -->
<!ATTLIST constraintnote
        %common-idreq.att;
        type            NMTOKEN         #REQUIRED>

<!-- ............................................................... -->
<!-- Basic display elements ........................................ -->
<!-- ............................................................... -->

<!--
#1998-03-23: maler: Added xml:space attribute.
-->

<!ELEMENT eg (%eg.pcd.mix;)*>
<!ATTLIST eg
        %common.att;
        %xmlspace.att;>

<!ELEMENT graphic EMPTY>
<!--    source attribute:
        The graphic data must reside at the location pointed to.
        This is a hypertext reference, but for practical purposes,
        for now it should just be a pathname. -->
<!ATTLIST graphic
        %common.att;
        %source-req.att;
        alt             CDATA           #IMPLIED>

<!-- ............................................................... -->
<!-- EBNF .......................................................... -->
<!-- ............................................................... -->

<!--
#1997-11-28: maler: Added prodgroup to scrap and defined it.
#1998-05-21: maler: Added constraint to prod.
-->

<!ELEMENT scrap (head, (prodgroup+ | prod+ | bnf))>
<!--    lang attribute:
        The scrap can link to a description of the language used,
        found in a language element in the header. -->
<!ATTLIST scrap
        %common.att;
        lang            IDREF           #IMPLIED>

<!ELEMENT prodgroup (prod+)>
<!--    pcw<n> attributes:
        Presentational attributes to control the width
        of the "pseudo-table" columns used to output
        groups of productions. -->
<!ATTLIST prodgroup
        %common.att;
        pcw1            CDATA           #IMPLIED
        pcw2            CDATA           #IMPLIED
        pcw3            CDATA           #IMPLIED
        pcw4            CDATA           #IMPLIED
        pcw5            CDATA           #IMPLIED
>

<!ELEMENT prod (lhs, (rhs, (com|wfc|vc|constraint)*)+)>
<!--    ID attribute:
        The production must have an ID so that cross-references
        (specref) and mentions of nonterminals (nt) can link to
        it. -->
<!ATTLIST prod
        %common-idreq.att;>

<!ELEMENT lhs (#PCDATA)>
<!ATTLIST lhs %common.att;>

<!ELEMENT rhs (#PCDATA|nt|xnt|com)*>
<!ATTLIST rhs %common.att;>

<!--      nt and xnt (defined in "Phrase-level elements" below) -->

<!--
#1997-11-28: maler: Added loc and bibref to com content.
-->

<!ELEMENT com (#PCDATA|loc|bibref)*>
<!ATTLIST com %common.att;>

<!--    wfc: Should generate the head of the wfcnote pointed to -->
<!ELEMENT wfc EMPTY>
<!--    def attribute:
        Each well formedness tagline in a production must link to the
        wfcnote that defines it. -->
<!ATTLIST wfc
        %def-req.att;
        %common.att;>

<!--    vc: Should generate the head of the vcnote pointed to -->
<!ELEMENT vc EMPTY>
<!--    def attribute:
        Each validity tagline in a production must link to the vcnote
        that defines it. -->
<!ATTLIST vc
        %def-req.att;
        %common.att;>

<!--
#1998-05-21: maler: Declared generic constraint element.
-->

<!--    constraint: Should generate the head of the constraintnote
        pointed to -->
<!ELEMENT constraint EMPTY>
<!--    def attribute:
        Each constraint tagline in a production must link to the
        constraint note that defines it. -->
<!ATTLIST constraint
        %def-req.att;
        %common.att;>

<!--
#1998-03-23: maler: Added xml:space attribute.
-->

<!--    bnf: Un-marked-up production -->
<!ELEMENT bnf (%eg.pcd.mix;)*>
<!ATTLIST bnf
        %common.att;
        %xmlspace.att;>

<!-- ............................................................... -->
<!-- Table ......................................................... -->
<!-- ............................................................... -->

<!--
#1997-10-16: maler: Added table mechanism.
#1997-11-28: maler: Added non-null system ID to entity declaration.
#                   Added HTML table module.
#1997-12-29: maler: IGNOREd SGML Open table model.
#1998-03-10: maler: Removed SGML Open table model.
#                   Merged html-tbl.mod file into main file.
#                   Added %common.att; to all HTML table elements.
#1998-05-14: maler: Replaced table model with full HTML 4.0 model.
#                   Removed htable in favor of table.
#                   Removed htbody in favor of tbody.
-->

<!ENTITY % cellhalign.att
        'align          (left|center
                        |right|justify
                        |char)          #IMPLIED
        char            CDATA           #IMPLIED
        charoff         CDATA           #IMPLIED'>

<!ENTITY % cellvalign.att
        'valign         (top|middle
                        |bottom
                        |baseline)      #IMPLIED'>

<!ENTITY % thtd.att
        'abbr           CDATA           #IMPLIED
        axis            CDATA           #IMPLIED
        headers         IDREFS          #IMPLIED
        scope           (row
                        |col
                        |rowgroup
                        |colgroup)      #IMPLIED
        rowspan         NMTOKEN         "1"
        colspan         NMTOKEN         "1"'>

<!ENTITY % width.att
        'width          CDATA           #IMPLIED'>

<!ENTITY % span.att
        'span           NMTOKEN         "1"'>

<!ELEMENT table
        (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
<!ATTLIST table
        %common.att;
        %width.att;
        summary         CDATA           #IMPLIED
        border          CDATA           #IMPLIED
        frame           (void|above
                        |below|hsides
                        |lhs|rhs
                        |vsides|box
                        |border)        #IMPLIED
        rules           (none|groups
                        |rows|cols
                        |all)           #IMPLIED
        cellspacing     CDATA           #IMPLIED
        cellpadding     CDATA           #IMPLIED>

<!ELEMENT caption (%p.pcd.mix;)*>
<!ATTLIST caption %common.att;>

<!ELEMENT col EMPTY>
<!ATTLIST col
        %common.att;
        %span.att;
        %width.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT colgroup (col)*>
<!ATTLIST colgroup
        %common.att;
        %span.att;
        %width.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT thead (tr)+>
<!ATTLIST thead
        %common.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT tfoot (tr)+>
<!ATTLIST tfoot
        %common.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT tbody (tr)+>
<!ATTLIST tbody
        %common.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT tr (th|td)+>
<!ATTLIST tr
        %common.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT th (%p.pcd.mix;|%p.mix;)*>
<!ATTLIST th
        %common.att;
        %thtd.att;
        %cellhalign.att;
        %cellvalign.att;>

<!ELEMENT td (%p.pcd.mix;|%p.mix;)*>
<!ATTLIST td
        %common.att;
        %thtd.att;
        %cellhalign.att;
        %cellvalign.att;>

<!-- ............................................................... -->
<!-- IDL structures for DOM specifications ......................... -->
<!-- ............................................................... -->

<!-- ............................................................... -->
<!-- Specialized entities for classes .............................. -->

<!ENTITY % idl-desc.class
        "p|note">

<!ENTITY % idl-tdef.class
        "typedef|constant|exception|reference|group">

<!ENTITY % idl-mod.class
        "module|interface">

<!ENTITY % idl-struct.class
        "struct|enum|sequence|union|typename">

<!ENTITY % idl-meth.class
        "method|attribute">

<!-- ............................................................... -->
<!-- Specialized entities for mixtures ............................. -->

<!--    Quick reference to content model mixtures:

                        desc tdef mod struct meth
group                     x    x   x    x      x
definitions, module       x    x   x
interface                 x    x               x
typedef, case, component                x
-->

<!ENTITY % idl-grp.mix
        "%idl-desc.class;|%idl-tdef.class;|%idl-mod.class;
        |%idl-struct.class;|%idl-meth.class;">

<!ENTITY % idl-defn.mix
        "%idl-desc.class;|%idl-tdef.class;|%idl-mod.class;">

<!ENTITY % idl-intfc.mix
        "%idl-desc.class;|%idl-tdef.class;|%idl-meth.class;">

<!ENTITY % idl-type.mix
        "%idl-struct.class;">

<!-- ............................................................... -->
<!-- Specialized entities for common attributes .................... -->

<!--    name attribute:
        Provides a name.  Required. -->
<!ENTITY % idl-name.att
        'name                   CDATA           #REQUIRED'>

<!--    type attribute:
        Provides a type.  Required. -->
<!ENTITY % idl-type.att
        'type                   CDATA           #REQUIRED'>

<!-- ............................................................... -->
<!-- Common IDL element ............................................ -->

<!ELEMENT descr ((%obj.mix;)*)>
<!ATTLIST descr %common.att;>

<!-- ............................................................... -->
<!-- IDL definition elements ....................................... -->

<!--    definitions: Top-level element for definitions -->
<!ELEMENT definitions (%idl-defn.mix;)+>
<!ATTLIST definitions %common.att;>

<!--    group: Element used to group a set of definitions -->

<!ELEMENT group (descr, (%idl-grp.mix;)*)>
<!ATTLIST group
        %common.att;
        %idl-name.att;>

<!--    interface: Definition of an interface. -->
<!ELEMENT interface (descr, (%idl-intfc.mix;)*)>
<!ATTLIST interface
        %common.att;
        %idl-name.att;
        inherits        CDATA           #IMPLIED>

<!--    module: Definition of a module. -->
<!ELEMENT module (descr, (%idl-defn.mix;)*)>
<!ATTLIST module
        %common.att;
        %idl-name.att;>

<!--    reference: Reference to some other declaration. -->
<!ELEMENT reference EMPTY>
<!ATTLIST reference
        %common.att;
        declaration     IDREF           #REQUIRED>

<!--    typedef: Definition of a named type -->
<!ELEMENT typedef (descr, (%idl-type.mix;))>
<!ATTLIST typedef
        %common.att;
        %idl-name.att;
        array.size      NMTOKEN         #IMPLIED>

<!--    struct: Declaration of a struct type -->
<!ELEMENT struct (descr, component+)>
<!ATTLIST struct
        %common.att;
        %idl-name.att;>

<!--    component: Declaration of a structural member -->
<!ELEMENT component (%idl-type.mix;)>
<!ATTLIST component
        %common.att;
        %idl-name.att;>

<!--    union: Declaration of a union type -->
<!ELEMENT union (descr, case+)>
<!ATTLIST union
        %common.att;
        %idl-name.att;
        switch.type     CDATA           #REQUIRED>

<!ELEMENT case (descr, (%idl-type.mix;))>
<!ATTLIST case
        %common.att;
        labels          CDATA           #REQUIRED>

<!--    enum: Declaration of an enum type -->
<!ELEMENT enum (descr, enumerator+)>
<!ATTLIST enum
        %common.att;
        %idl-name.att;>

<!ELEMENT enumerator (descr)>
<!ATTLIST enumerator
        %common.att;
        %idl-name.att;>

<!--    sequence: Declaration of a sequence type (not named) -->
<!ELEMENT sequence (sequence*)>
<!ATTLIST sequence
        %common.att;
        %idl-type.att;
        size            NMTOKEN         #IMPLIED>

<!--    constant: Declaration of a named constant -->
<!ELEMENT constant (descr)>
<!ATTLIST constant
        %common.att;
        %idl-name.att;
        %idl-type.att;
        value           CDATA           #REQUIRED>

<!--    exception: Declaration of an exception -->
<!ELEMENT exception (descr, component*)>
<!ATTLIST exception
        %common.att;
        %idl-name.att;>
<!-- component (defined under struct, above)-->

<!--    attribute: Declaration of an attribute (data member) -->
<!ELEMENT attribute (descr)>
<!ATTLIST attribute
        %common.att;
        %idl-name.att;
        %idl-type.att;
        readonly        (yes
                        |no)            "no">

<!--    method: Declaration of a method -->
<!ELEMENT method (descr, parameters, returns, raises)>
<!ATTLIST method
        %common.att;
        %idl-name.att;>

<!ELEMENT parameters (param*)>
<!ATTLIST parameters %common.att;>

<!ELEMENT param (descr)>
<!ATTLIST param
        %common.att;
        %idl-name.att;
        %idl-type.att;
        attr            (in
                        |out
                        |inout)         "inout">

<!ELEMENT returns (descr)>
<!ATTLIST returns
        %common.att;
        %idl-type.att;>

<!ELEMENT raises (exception*)>
<!-- exception (defined under constant, above)-->

<!ELEMENT typename (#PCDATA)>
<!ATTLIST typename %common.att;>

<!-- ............................................................... -->
<!-- Phrase-level elements ......................................... -->
<!-- ............................................................... -->

<!--    bibref: Should generate, in square brackets, "key" on bibl -->
<!ELEMENT bibref EMPTY>
<!--    ref attribute:
        A bibliography reference must link to the bibl element that
        describes the resource. -->
<!ATTLIST bibref
        %common.att;
        %ref-req.att;>

<!ELEMENT code (%tech.pcd.mix;)*>
<!ATTLIST code %common.att;>

<!--
#1998-03-10: maler: Declared ednote and related elements.
-->

<!ELEMENT ednote (name?, date?, edtext)>
<!ATTLIST ednote %common.att;>

<!ELEMENT date (#PCDATA)>
<!ATTLIST date %common.att;>

<!ELEMENT edtext (#PCDATA)>
<!ATTLIST edtext %common.att;>

<!ELEMENT emph (#PCDATA)>
<!ATTLIST emph %common.att;>

<!--    footnote: Both footnote content and call to footnote -->
<!ELEMENT footnote (%obj.mix;)+>
<!ATTLIST footnote %common.att;>

<!ELEMENT kw (%tech.pcd.mix;)*>
<!ATTLIST kw %common.att;>

<!ELEMENT loc (#PCDATA)>
<!--    HREF attribute:
        The purpose of a loc element is to function as a A-like
        hypertext link to a resource.  (Ideally, the content of loc
        will also mention the URI of the resource, so that readers of
        the printed version will be able to locate the resource.) E.g.:

<loc href="http://www.my.com/doc.htm">http://www.my.com/doc.htm</loc>
        -->
<!ATTLIST loc
        %common.att;
        %href-req.att;>

<!ELEMENT nt (#PCDATA)>
<!--    def attribute:
        The nonterminal must link to the production that defines
        it. -->
<!ATTLIST nt
        %common.att;
        %def-req.att;>

<!--
#1998-03-10: maler: Declared quote.
-->

<!--    quote: Scare quotes and other purely presentational quotes -->
<!ELEMENT quote (%p.pcd.mix;)*>
<!ATTLIST quote %common.att;>

<!--    specref: Should generate italic "[n.n], Section Title" for
        div, "n" for numbered item, "[n]" for production, or
        "Issue n" for issue -->
<!ELEMENT specref EMPTY>
<!--    ref attribute:
        The purpose of a specref element is to link to a div, item
        in an olist, or production in the current spec. -->
<!ATTLIST specref
        %common.att;
        %ref-req.att;>

<!ELEMENT term (#PCDATA)>
<!ATTLIST term %common.att;>

<!ELEMENT termdef (%termdef.pcd.mix;|%termdef.mix;)*>
<!--    ID attribute:
        A term definition must have an ID so that it can be linked
        to from termref elements. -->
<!--    term attribute:
        The canonical form of the term or phrase being defined must
        appear in this attribute, even if the term or phrase also
        appears in the element content in identical form (e.g., in
        the term element). -->
<!ATTLIST termdef
        %common-idreq.att;
        term            CDATA           #REQUIRED>

<!ELEMENT termref (#PCDATA)>
<!--    ref attribute:
        A term reference must link to the termdef element that
        defines the term. -->
<!ATTLIST termref
        %common.att;
        %def-req.att;>

<!ELEMENT titleref (#PCDATA)>
<!--    HREF attribute:
        A title reference can optionally function as a hypertext
        link to the resource with this title.  E.g.:

<loc href="http://www.my.com/doc.htm">http://www.my.com/doc.htm</loc>
        -->

<!ATTLIST titleref
        %common.att;
        %href.att;>

<!ELEMENT xnt (#PCDATA)>
<!--    HREF attribute:
        The nonterminal must hyperlink to a resource that serves
        to define it (e.g., a production in a related XML
        specification).  E.g.:

<xnt href="http://www.w3.org/TR/spec.htm#prod3">Name</xnt>
        -->

<!ATTLIST xnt
        %common.att;
        %href-req.att;>

<!--
#1997-12-29: maler: Declared xspecref.
-->

<!ELEMENT xspecref (#PCDATA)>
<!--    HREF attribute:
        The spec reference must hyperlink to the resource to
        cross-refer to (e.g., a section in a related XML
        specification).  E.g.:

<xspecref href="http://www.w3.org/TR/spec.htm#sec2">
the section on constraints</xspecref>
        -->

<!ATTLIST xspecref
        %common.att;
        %href-req.att;>

<!ELEMENT xtermref (#PCDATA)>
<!--    HREF attribute:
        The term reference must hyperlink to the resource that
        serves to define the term (e.g., a term definition in
        a related XML specification).  E.g.:

<xtermref href="http://www.w3.org/TR/spec.htm#term5">
entity
</xtermref>
        -->

<!ATTLIST xtermref
        %common.att;
        %href-req.att;>

<!-- ............................................................... -->
<!-- Unused elements for ADEPT ..................................... -->
<!-- ............................................................... -->

<!--
#1997-09-30: maler: Added unusued elements.
#1997-10-14: maler: Fixed div to move nested div to the mixture.
#1998-05-14: maler: Added key-term, htable, and htbody.
-->

<!--    The following elements are purposely declared but never
        referenced.  Declaring them allows them to be pasted from
        an HTML document or an earlier version of an XML spec document
        into a document using this DTD in ADEPT.  The ATD Context
        Transformation mechanism will try to convert them to the
        appropriate element for this DTD.  While this conversion will
        not work for all fragments, it does allow many cases to work
        reasonably well. -->

<!ELEMENT div
        (head?, (%div.mix;|ul|ol|h1|h2|h3|h4|h5|h6|div)*)>
<!ELEMENT h1 (%head.pcd.mix;|em|a)*>
<!ELEMENT h2 (%head.pcd.mix;|em|a)*>
<!ELEMENT h3 (%head.pcd.mix;|em|a)*>
<!ELEMENT h4 (%head.pcd.mix;|em|a)*>
<!ELEMENT h5 (%head.pcd.mix;|em|a)*>
<!ELEMENT h6 (%head.pcd.mix;|em|a)*>
<!ELEMENT pre (%eg.pcd.mix;|em)*>
<!ELEMENT ul (item|li)*>
<!ELEMENT ol (item|li)*>
<!ELEMENT li (#PCDATA|%obj.mix;)*>
<!ELEMENT em (#PCDATA)>
<!ELEMENT a (#PCDATA)>

<!ELEMENT key-term (#PCDATA)>
<!ELEMENT htable
        (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
<!ELEMENT htbody (tr)+>
<!ELEMENT statusp (%p.pcd.mix;|%p.mix;)*>

<!-- ............................................................... -->
<!-- Change history ................................................ -->
<!-- ............................................................... -->

<!--
#1997-08-18: maler
#- Did a major revision.
#1997-09-10: maler
#- Updated FPI.
#- Removed namekey element and put key attribute on name element.
#- Made statusp element and supporting entities.
#- Added slist element with sitem+ content.
#- Required head on scrap and added new bnf subelement.
#- Added an xnt element and allowed it and nt in regular text and rhs.
#- Removed the ntref element.
#- Added back the com element to the content of rhs.
#- Added a key attribute to bibl.
#- Removed the ident element.
#- Added a term element to be used inside termdef.
#- Added an xtermref element parallel to termref.
#- Beefed up DTD comments.
#1997-09-12: maler
#- Allowed term element in general text.
#- Changed bibref to EMPTY.
#- Added ref.class to termdef.pcd.mix.
#1997-09-14: maler
#- Changed main attribute of xtermref from def to href.
#- Added termdef.class to label contents.
#1997-09-30: maler
#- Added character entity module and added new entities.
#- Removed p from appearing directly in self; created %p.mix;.
#- Added inform-div (non-normative division) element.
#- Fixed xtermref comment to mention HREF, not ref.
#- Extended orglist model to allow optional affiliation.
#- Modified author to make affiliation optional.
#- Added %speclist.class; and %note.class; to %obj.mix; and %p.mix;.
#- Added %note.class; and %illus.class; to %termdef.pcd.mix;.
#- Added unused HTML elements.
#- Put empty system ID next to public ID in entity declarations.
#1997-10-14: maler
#- Fixed "unused" div content model to move nested div to mixture.
#1997-10-16: maler
#- Added SGML Open Exchange tables.
#1997-11-28: maler
#- Added support for prodgroup and its attributes.
#- Added support for HTML tables.
#- Added loc and bibref to content of com.
#- Added loc to general p content models.
#- Allowed p as alternative to statusp in status.
#- Added non-null system IDs to external parameter entity declarations.
#- (Modified the SGML Open table module to make it XML-compliant.)
#- (Modified the character entity module.)
#1997-12-29: maler
#- Moved #PCDATA occurrences to come before GIs in content models.
#- Removed use of the SGML Open table module.
#- Added xspecref element.
#- Ensured that all FPIs contain 4-digit year.
#- (Modified the character entity module.)
#1998-03-10: maler
#- Merged the character entity and table modules into the main file.
#- Added ldquo and rdquo entities.
#- Added common attributes to prodgroup.
#- Made the email element in header optional.
#- Removed reference to the SGML Open table model.
#- Added ednote element.
#- Added quote element.
#- Updated XLink usage to reflect 3 March 1998 WD.
#- Added "local" entities to the class entities for customization.
#- Parameterized several content models to allow for customization.
#1998-03-23: maler
#- Cleaned up some comments and removed some others.
#- Added xml:space semi-common attribute to eg and bnf elements.
#- Added show and embed attributes on all the uses of href.
#- Added %common.att; to all HTML table elements.
#- Added a real URI to the "typical invocation" comment.
#1998-05-14: maler
#- Fixed mdash, ldquo, and rdquo character entities.
#- Switched to the full HTML 4.0 table model.
#- Removed htable/htbody elements and replaced them with table/tbody.
#- Added issue element to %note.class; and declared it.
#- Allowed prevlocs and latestloc in either order.
#- Added key-term, htable, htbody, and statusp as unused elements.
#- Removed real statusp element in favor of plain p.
#1998-05-21: maler
#- Declared generic constraint and constraintnote elements.
#- Added constraintnote to %note.class;.
#- Added constraint to %eg.pcd.mix; and prod content model.
#1998-08-22: maler
#- Fixed %illus.class; to mention table instead of htable.
#- Added definitions to %illus.class; for DOM model.
#- Added DOM definitions element and its substructure.
#- Updated XLink usage in %href.att; to use xlink:form and #IMPLIED.
#- Added clarifying comments to HREF-using elements.
-->

<!-- ............................................................... -->
<!-- End of XML specification DTD .................................. -->
<!-- ............................................................... -->