This report describes the XML specification ("XMLspec") DTD used
for World Wide Web Consortium (W3C) specifications and notes
related to XML. It is maintained by Eve Maler (<elm@east.sun.com>, +1
781 442 3190) of Sun Microsystems. This release of the report
corresponds to the DTD with the formal public identifier "-//W3C//DTD Specification Version
2.1//EN".

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.

Appendix A contains a non-normative list of
known applications that do formatting and other processing of
XMLspec documents.

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

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.

In recent revisions, the markup has evolved to capture an
increasing amount of technical detail, for example, the IDL
structures contributed from the DOM work. This is motivated
entirely by considerations of successful publication from a single
source to multiple outputs, rather than by abstract concerns about
source purity; however, it makes an effective illustration of the
power of XML.

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.

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.

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.

This DTD's first few revisions existed before there were any XML
parsers, and indeed before XML 1.0 itself was standardized. In
today's world, XML's future has been assured and XML tools are
plentiful. However, while a "proof of concept" is no longer needed,
XMLspec does in fact continue to serve as an example of best
practices.

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.

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

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

For easier identification, the DTD now uses a formal public
identifier in the following pattern:

-//W3C//DTD XML Specification Version n.n//EN

The current version is identified as:

-//W3C//DTD Specification Version 2.1//EN

The policy, beginning with Version 2.0, is as follows.

Minor revisions (revising
n.m to produce n.m+1, for example, going from V2.0
to V2.1 or from V2.1 to V2.2) can add to the markup model, but
cannot change it in a backwards-incompatible way. For example, a
new kind of list element could be added, but it would not be
acceptable for the existing itemized-list model to start requiring
two list items inside it instead of only one. Thus, any document
conforming to an old version would also conform to the new minor
revision.

Major revisions (revising
n.m to produce (n+1).0, for example, going from
V2.1 to V3.0) can both add to the markup model and make
backwards-incompatible changes. Ideally these will be accompanied
by XSLT transformation specifications that help legacy documents to
conform to the new version.

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 within the W3C. A more formal
procedure may be put in place later.

This DTD does not yet have an official schema. If you want to
refer to the XMLspec vocabulary for namespace management purposes,
use the following URI to identify it:

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 and
content models.

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.att

An empty placeholder that is available to be used in extending
an attribute list.

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.

The DTD conforms to XML V1.0 and makes use of the XML and XLink
namespaces. Because DTDs and namespaces don't mix well, the xlink namespace prefix has been hardwired.
(The xml prefix is hardwired into the XML
specification itself.)

While XLink is used for all URI-style linking, the IDREF addressing mechanism is still used
heavily for internal links. As support for the XPointer construct
xpointer(id("xxx")) grows and that
specification stabilizes, we will consider moving to this style of
addressing for internal linking.

This version of the DTD does not yet conform fully to the latest
working draft of the XLink specification, because this would have
required backwards-incompatible changes. When the XLink
specification reaches Recommendation status and if such
backwards-incompatible changes are still required, a new major
version of this DTD will be published that will require changes to
legacy documents.

The DTD is beginning to be used more widely by W3C contributors
(as well as by authors of non-W3C specifications). 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

Addition of new attributes to an attribute list

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:

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

Revise XLink usage as necessary. Note that in the current
version, all the XLink simple linking elements in this DTD do not conform to the latest XLink working
draft; a major revision of XMLspec (along with conversions of
legacy documents) will be needed to bring it back into sync. See the section called XLink-Related Attributes
in Chapter 2 for more information.

According to W3C guidelines (http://www.w3.org/Guide/Reports), 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.
Consider migrating over to this scheme at the next major revision
(because it is backwards incompatible).

Research the proper form of Web resource bibliography entries,
and consider adding to the structure of
bibl to optimize for it.

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").

Dan Connolly 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

The
source attribute would also have to be renamed to src

emph

em

If a glossary list is used to organize term definitions, how can
termdef properly be used? Currently, at
least in the XML Linking 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.

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

Incorporate the XHTML 1.0 table model, now that it's a
Recommendation.

Add an inline graphic element.

Consider adding attributes to division elements to record
whether the division has WG consensus, whether it is obsolete,
etc.

At the next major revision (because it is
backwards-incompatible):

Require the abstract to go before the status section

Fix the order of prevlocs and latestloc

Revise XLink usage in backwards-incompatible ways as
necessary

Require graphic alt text

Require issue heads?

Change over to use constraint and constraintnote exclusively,
since only the XML spec needs wfc/wfcnote and vc/vcnote?

Consider changes to BNF internal structure? (Check against
DocBook's use of the BNF structure)

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.

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.

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.

The diff attribute indicates
whether a particular element has changed since the last version of
the document, which a stylesheet can act on if necessary. When a
value is not provided for an element, it should inherit a value
from its parent. If the root element has no value supplied, assume
"off". The diff attribute can have one
of four values: "add" (the element was added), "chg" (the element
or its content was changed), "del" (the element was deleted), or
"off" (even though a higher-level element has one of the other
three values, this subelement has not changed). The %common.att; and
%common-idreq.att; entities both contain diff, in optional form.

Difference values may or may not be operated on by stylesheets.
For example, changed and added content may be presented in a
different color or emboldened, and deleted content may have its
text struck through or may be suppressed entirely. Alternatively,
the values may be used to control marginal change bars.

This attribute is not intended to take the place of a full code
versioning or content management system; rather, difference values
will help specification authors manage the process of issuing new
revisions and accepting comments. Currently, some specification
authors use differencing tools to compare the generated HTML
versions and produce difference formatting. This markup will allow
them to reflect the differences directly in the XML form, which is
sometimes used as a final form for viewing.

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.

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:

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 all cases:

For the "ref" elements, the content of the element should allow
the user to link to the additional information. For the "recap"
element, the link should embed the content of the target at the
point of reference (much like an XLink "embed", though XLink is not
being used here yet).

A set of parameter entities helps to manage the XLink-related
attributes. The %simple-xlink.att; entity
sets up the xmlns:xlink and xlink:type attributes, which declare the
following element types to be XLink simple links:

email

bibl

graphic

loc

titleref

xnt

xspecref

xtermref

The %href.att; and
%href-req.att; entities set up the
href attribute (in optional and required forms), which
allows most of the simple XLink elements to point to their targets.
When a value for href is supplied (as
it will be in all the required cases), The simple links will be
traversable. The href attribute is
available on the following elements:

email

bibl (optional)

loc

titleref (optional)

xnt

xspecref

xtermref

Conformance Note: Because the current Working Draft of
the XLink specification has removed certain features, proper usage
now requires that XLink-related attributes have a namespace prefix.
However, because this would require a disruptive
backwards-incompatible change, the eight simple XLink elements in
XMLspec are not quite conforming. In a future version, the seven
elements using href will be changed to
have a prefix, and the graphic element
(which has a source attribute) will
need to switch to a prefixed href
attribute.

Several parameter entities are set up for convenience of
applying XLink behavior semantics. The
%auto-embed.att;, %user-replace.att;,
and %user-new.att; entities set up the
XLink show and
actuate attributes. The simple XLink elements have these
settings:

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 the section called Specification Header
(header) 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 four additional levels, down to
div5. 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.

In addition to the common attributes, the
spec element has three unique attributes:

w3c-doctype

Indicates the type of document, so that the appropriate
stylesheet or workflow routing can be applied. It can optionally
have a value of "rec" (Recommendation), "pr" (Proposed
Recommendation), "cr" (Candidate Recommendation), "wd" (Working
Draft), "note" (Note), "issues" (Issues List), "dispcmts"
(Disposition of Comments), or "other". It should not generate any text (such as the "REC-" or
"NOTE-" prefix on the W3C designation content). It has no default.
If this value is "other",
other-doctype should be filled in.

other-doctype

If w3c-doctype is "other", this
value should be filled in with a keyword chosen or negotiated by
the document authors and rendering application developers. It has
no default.

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.

The w3c-doctype attribute should not be used to generate any text (such as the
"REC-" or "NOTE-" prefix on the W3C designation content). The value
of the status attribute might affect
the stylesheet's treatment of editorial notes (for example, whether
to output them).

Originally, divisions went down to four levels total (to div4), but the MathML specification required
one more level.

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.

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 (optional)

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,
"W3C Working Draft" or "W3C 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 one or more Web resources corresponding to the different
published forms (for example, XML, HTML, and PostScript) of this
technical report. It contains character data and phrase-level
elements (see Table 7-2), typically
just one or more loc elements.

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 character
data and phrase-level elements (see Table
7-2), typically just one or more loc
elements. If there are no previous versions, the prevlocs element itself should not be
provided.

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 character data and
phrase-level elements (see Table 7-2),
typically just one or more loc
elements.

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.

copyright (optional)

A copyright notice. W3C now requires that specifications have
copyright notices.

The copyright element contains a
mixture of standalone elements (see
Table 7-1). Note that its content should be "cooked," that is,
the author should not rely on a rendering process to produce a
copyright symbol, punctuation, or other style elements that might
make up a proper copyright notice. These should be provided
directly in the XML source.

abstract (can appear after status)

A brief description of the document contents. It contains a
mixture of zero or more standalone elements (see Table 7-1). Putting the abstract
after the status statement is deprecated.

status (can appear before
abstract)

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

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.

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 attributes, 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.

The content of publoc, prevlocs, and
latestloc was broadened so that the various published forms
and auxiliary resources of a specification can be mentioned. For
example, the XML Schema specifications refer not only to the XML
source and the HTML published form, but also to the special
stylesheet used to produce the output and normative DTDs and
schemas associated with the specification.

W3C publication guidelines require the abstract to come before
the status statement; it is allowed after the status statement only
for backwards compatibility with V2.0 of the DTD.

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 version element was made optional for Version
2.0 of the DTD because versions are not required on Working
Drafts.

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.

It was decided to make the copyright
element contain "cooked" content for simplicity and so that it is
most likely that various renderings of the document will contain
the correct copyright notice, whole and uncut. It is expected that
if the XML source itself needs to have
explicit copyright protection, an XML comment (in each file making
up the document) is the right tool for the job.

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.)

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 locanywhere 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 the section called
URI Reference (loc) in Chapter 5)
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.

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.

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).

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.

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.

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)

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.

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."

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).

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.

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.

The issue element is for the text of
outstanding issues related to the technical report. It contains an
optional head, an optional series of source elements that describe the
communication (typically a document or email message) in which the
issue was raised, a mixture of one or more standalone elements (see
Table 7-1), and an optional resolution element.

In addition to the common attributes, it also has the status attribute, which can have a value of
"open" (the default) or "closed". It it possible for an issue with
no resolution provided to be closed.

Issues should be formatted as vertically set-off content with
some kind of generated "Issue" heading, the issue ID, and the issue
head (if any) prominently displayed. The source and resolution
information should be given generated heading as necessary. It is
expected that an xref element referring to
an issue will refer to it by its issue ID.

The status attribute may control,
for Recommendation-track documents, whether the issue is output at
all; closed issues could be suppressed. Issues-list and errata
documents might want to print all issues.

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 the section called Code Scrap
(scrap)).

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
constraintnote should be used to trigger the appropriate
generated heading and to contribute to the appearance of the
related constraint elements.

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.

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.

The element should be displayed as vertically set off (even if
it appears inside a paragraph), with a generated "Example" heading
of some kind, followed by the supplied head text (if any).
Typically, in HTML form it is displayed as a table with one column
and a background color that distinguishes it from the surrounding
content..

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.

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, but for now, the graphic element
is not strictly XLink-conforming because the ability to do
attribute remapping has gone away. The fixed-value attribute xml:attributes on this element was therefore
removed.

The scrap element identifies a code
scrap containing language productions. It contains, in order, a head element containing character data,
followed by a free mixture of one or more
bnf, prod,
prodgroup, and prodrecap
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 the section called Specification
Reference (specref) in Chapter 5)
and nt mentions of nonterminals (see the section called Nonterminal Reference (nt) in Chapter 5) 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 prodrecap element links to an
existing production for the purpose of reproducing it in this
location for the reader's convenience. It is empty and has a
required ref attribute to the desired
production.

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.

A presentational attribute to control the output of the scrap
head. The default is "show", the other possible value is
"suppress". The head should be suppressed only if the scrap appears
in like-named section and there is no other content in the section,
such that the section head and the scrap head would merely repeat
each other.

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.

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. If the
scrap element's headstyle
attribute is set to "suppress", the scrap head should be suppressed
from output.

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.

Originally, the content model for a scrap called for either a bnf element
or one or more
prod elements or one or more prodgroup elements. This strong separation of
each type of scrap content began to seem unwarranted when the prodrecap element was added, since it seems
eminently possible to format the result even when all four
subelements are mixed freely. Thus, the content model was
broadened.

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.

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.

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.

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. See the XML source for the
DOM Recommendation for examples, and 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.

Each function prototype is expected to be displayed vertically
set off, with the function name emphasized. It should be flanked on
the left by the return type and on the right by a list of argument
types. If a particular argument is optional, is should be indicated
so. Depending on the language being described, the list is
typically parenthesized and the argument types separated by commas,
with optional arguments being followed by question marks.

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.)

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.

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.

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 the section called
Issues in Chapter 1.)

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.

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.

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.

The phrase element identifies text that
needs attribute values set on it, but is otherwise undistinguished
from the surrounding text. It contains a mixture of character data
and the same phrase-level elements that are allowed in paragraphs
(see Table 7-2).

The content of the phrase should be given no special
typographical emphasis compared to the surrounding text, except as
dictated by the attributes on the element. For example, a role or diff value
could have an effect on presentation.

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).

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).

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.

This element is allowed in a wide variety of places because (as
noted in issue 3 in the
section called Issues in Chapter 1) 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.

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).

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.

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.

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.

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.

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 the section
called Defined Term (term)).
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.

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).

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 the
section called Issues in Chapter 1.

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.

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 the section called Issues in Chapter
1.

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.

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.

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 the
section called Defined Term (term)). It contains character data
(see Table 7-2).

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.

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.

The att element contains the mention of
an attribute name in text. (Note that it is not the same and does
not have the same purpose as the attribute
element, used exclusively in the
definitions element.) It contains a mixture of character data
and phrase-level elements (see Table
7-2).

This element is more precise than the
kw or code element and should be used
only when an XML attribute name appears by itself in text. An
entire start-tag with attribute specifications, for example, should
use code.

The attvalue element contains the
mention of an attribute value or potential attribute value in text.
(Note that it is not the same and does not have the same purpose as
the attribute element, used exclusively in
the definitions element.) It contains a
mixture of character data and phrase-level elements (see Table 7-2).

This element is more precise than the
kw or code element and should be used
only when an XML attribute value appears by itself in text. An
entire start-tag with attribute specifications, for example, should
use code. This element is useful, for
example, for explaining the individual token values available on an
attribute.

The content of the element should be given typographical
distinction, possibly being surrounded by quotation marks. The
element could also be pulled into a paper or electronic index for
reference to the locations where the attribute value is
mentioned.

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.

The el element contains the mention of
an element type name, or generic identifier (GI), in text. It
contains a mixture of character data and phrase-level elements (see
Table 7-2).

This element is more precise than the
kw or code element and should be used
only when an XML element type name appears by itself in text. An
entire start-tag with attribute specifications, for example, should
use code.

The content of the element should be given typographical
distinction, possibly surrounded by angle brackets. The element
could also be pulled into a paper or electronic index for reference
to the locations where the element type is mentioned.

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).

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.

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).

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.

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 var element identifies a string
that, in actual usage, should be supplied by a human or computer
according to the circumstances. This is somewhat similar to the
MathML element mi. For example, reference
to "some node x" would use var for the "x" part. It contains a mixture of
character data and phrase-level elements (see Table 7-2).

Note that this element is not for programming or system variable
names.

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 the section called Code Scrap (scrap) in Chapter 4). It contains
character data (see Table 7-2).

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.

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.

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
element contains character data, and the
edtext element contains a mixture of character data and
phrase-level elements (see Table
7-2).The name element is discussed
along with the specification header element, in
the section called Specification Header (header) in Chapter 3.

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.

Originally, we thought that 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. However, editors were finding it
useful to transplant "temporary" text to and from editorial notes,
so starting to allow inline markup made sense.

Use for email addresses that appear in text. This element allows
the appearance of the email address in text to serve as a (usually
mailto:) URL that can be accessed. For
example:<email
href="mailto:elm@arbortext.com">elm@arbortext.com</email>

It could be argued that this is a redundant form. However, it is
desirable to allow this element to be an XLink-conforming element
that has the desired behavior, without the
need for transformation into HTML.

Pull in graphic data and
display in place automatically (if image loading is on) (XLink
"auto"/"embed").

loc

External resource

Req

URI

Use for generic HTML
A-type references that don't fall into any
of the other categories of URI-mechanism links. Because XML
specifications are often read in hardcopy form, try to include the
URL in the actual document text. It's better to make a proper
bibliography entry and include the URL as part of the entry.

Allow traversal from
the mention of the location to the location itself by clicking
(XLink "user"/"replace").

titleref

External resource

Opt

URI

Use for making the
mention of a title of a Web resource "hot." Best used only in the
context of a bibliography entry, so that external references are
relegated to the bibliography as much as possible. For example: <titleref
href="http://www.pmi.org/publictn/pmboktoc.htm">PMI Body of
Knowledge</titleref>

Allow traversal from
the mention of the document's title to the document itself by
clicking (XLink "user"/"new").

xnt

External resource

Req

URI

Use to associate the
mention of a nonterminal with the production in
another specification that has this nonterminal as its
left-hand side. For example: <xnt
def="http://www.w3.org/TR/WD-xml#foo-prod">foo</xnt>

Allow traversal from
the mention of the nonterminal to the (remote) production for it by
clicking (XLink "user"/"new").

xspecref

External resource

Req

URI

Use for making a
cross-reference to an external specification (or a portion of one).
For example: <xspecref
def="http://www.w3.org/TR/WD-xml-names">Namespaces in
XML</xspecref>

Allow traversal from
the mention of the spec reference to the (remote) location where
the spec is discussed by clicking (XLink "user"/"new").

xtermref

External resource

Req

URI

Use for associating
the mention of a term with its definition in
another specification. For example:
<xtermref
def="http://www.w3.org/TR/REC-xml#entity-def">entity</xtermdef>

Allow traversal from
the mention of the term to the (remote) location where the term is
defined by clicking (XLink "user"/"new").

ID/IDREF Links

bibref

bibl

Req

IDREF

Use to associate a
bibliographic citation in text with the corresponding bibliography
entry. For example: <bibref
ref="rfc1234"/>

Allow traversal from
bibliographic reference to the bibliographic entry by clicking
(analogue of XLink "user"/"new").

constraint

constraintnote

Req

IDREF

Use to associate the
constrained production with the explanation of the constraint. For
example: <constraint
def="constraint3"/>

Generate the head text of
the note and other surrounding text, and output in place; use the
type attribute on the note to
determine the type.

nt

prod

Req

IDREF

Use to associate the
mention of a nonterminal with the production that has this
nonterminal as its left-hand side. For example: <nt def="foo-prod">foo</nt>

Allow traversal from the
nonterminal to the production that defines it by clicking (analogue
of XLink "user"/"new").

prodrecap

prod

Req

IDREF

Use to pull in an extra
copy of a production in the location of the link. For example: <prodrecap ref="QName.prod"/>

Reproduce the entire
production (without a number next to it, or with some other
indication that this is not the primary place where the production
is defined) and display in place automatically (analogue of XLink
"auto"/"embed").

scrap

language in langusage

Req

IDREF

Use to indicate the
language used in the code scrap. For example:
<scrap lang="ebnf">...</scrap>

None.

specref

div1, div2, div3, inform-div1

Req

IDREF

Use for making a
cross-reference to a division in the current document.

Generate, in place, an
italic "[n.n], Section Title" reference based on the relevant
information from the referenced division; allow traversal from the
generated text to the division by clicking (analogue of XLink
"user"/"new").

specref

item in olist

Req

IDREF

Use for making a
cross-reference to a list item in the current document.

Generate, in place, the
sequential number of the referenced item; allow traversal from the
generated text to the item by clicking (analogue of XLink
"user"/"new").

specref

prod

Req

IDREF

Use for making a
cross-reference to a production in the current document.

Generate, in place, the
number of the production in brackets; allow traversal from the
generated text to the production by clicking (analogue of XLink
"user"/"new").

specref

issue

Req

IDREF

Use for making a
cross-reference to an issue in the current document.

Generate, in place,
"Issue" and the number of the issue; allow traversal from the
generated text to the issue by clicking (analogue of XLink
"user"/"new").

termref

termdef

Req

IDREF

Use for associating the
mention of a term with its definition. For example: <termdef
def="entity-def">entity</termdef>

Allow traversal from the
mention of the term to the location where the term is defined by
clicking (analogue of XLink "user"/"new").

vc

vcnote

Req

IDREF

Use to associate the
constrained production with the explanation of the constraint. For
example: <vc
def="vconstraint2"/>

Generate the head text of
the note and other surrounding text, and output in place.

wfc

wfcnote

Req

IDREF

Use to associate the
constrained production with the explanation of the constraint. For
example: <wfc
def="wfconstraint1"/>

Generate the head text of
the note and other surrounding text, and output in place.

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)

Phrase (phrase)

Quoted text (quote)

Subscripted text (sub)

Superscripted text (sup)

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)

Function (function)

Variable (var)

Element type name (el)

Attribute name (att)

Attribute value (attval)

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.

Following are known applications that format or otherwise
process XMLspec documents. No claims are made about their
usability, or to their conformance to new versions of the XMLspec
DTD. If you have a processing application for XMLspec that you'd
like to publicize, please contact Eve Maler.

Name

Description

Status

Author

Availability

Jade stylesheets

DSSSL stylesheets for
formatting XMLspec documents, one version using standard DSSSL flow
objects for producing hardcopy (RTF, TeX etc) and one version using
SGML transformation flow objects for producing HTML.

Developed as far as
needed for production of original versions of XML and XSL
specs.

XSLT stylesheet to
convert both the XML specification and the XSL specification into
HTML. It was developed as as an exercise to identify missing
functionality in XSL.

This is an
experimental stylesheet, written for a limited purpose. No
commitment is made to keep it up to date. Note that the stylesheet
uses two extensions to XSL [next-element()
and previous-element()] implemented only
in James Clark's 19990307 version of XT.