Continuing Education on New Data Standards & Technologies

Search thousands of Continuing Education resources for metadata professionals


Advanced Search

Design Report for the W3C XML Specification DTD

Go to the resource directly at http://xml.coverpages.org/xmlspec-report-19980407.html

Linked Data

Subject

Creator

Dublin Core

Title

Design Report for the W3C XML Specification DTD

Description

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:

This report is organized as follows:

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

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.

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

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

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:

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

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.

The following information gives background on implementation decisions.

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

The current version is identified as:

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.

The original element names 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.

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

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. 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 mechanism is still used heavily for internal links. As support for the Xpointer construct grows, we will consider moving to this style of link for these cases.

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:

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:

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

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

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 .

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 nearly always serve as the target of a link:

The entity is used for those elements that don't require an id attribute, and the entity is used for those elements that do require an id attribute.

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

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 can be used both by attributes and by XPointers. The unique identification of an element does not presume a linking solution.

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 . The and entities both contain role, in optional form.

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

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

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

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:

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.

It was felt that a subelement solution to the problem of sorting (in the case of ) 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 mechanism. The parameter entity is used for optional def attributes (of which there are currently none), and the parameter entity is used for required def attributes.

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

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

The mechanism was used for now, until the XLink mechanism is more widely supported.

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

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

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

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

The mechanism was used for now, until the XLink mechanism is more widely supported.

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

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 parameter entity is used for optional href attributes and their related XLink attributes, and the 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:

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

The source attribute points to the file where the graphic source data can be found; it is always required. The 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:

In general, the content of elements with an href attribute should allow the user to link to the resource. The 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, see Section 6.1.

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

The align attribute specifies horizontal spacing. If this attribute is used on the element, it will specify the placement of the entire table. The default for the entire table is specified on the element. The table's default value can be overridden on lower-level elements within the table. For instance, if it is used on element, the horizontal alignment will be specified for all the cells in a particular row, or for a particular cell if specified on . In most cases a value is optional; it has possible values of “left”, “center”, and “right”.

The align attribute appears on the following elements:

It is expected that this HTML-based table markup will be trivially converted into real HTML markup and operated on in the usual way.

The valign attribute specifies vertical spacing. If it is used on the element, the vertical alignment will be specified for all the cells in the particular row, or for a particular cell if specified on . A value is optional; it has possible values of “top”, “middle”, and “bottom”.

The valign attribute appears on the following elements:

It is expected that this HTML-based table markup will be trivially converted into real HTML markup and operated on in the usual way.

The element contains, in order, a ; an optional ; a ; and an optional .

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 and contain one or more elements. The main element for structuring content is , the equivalent of a preface, chapter, or appendix. It can be subdivided to three additional levels, down to . At each level, the division contains a (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 ).

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

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

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

The original element, which wrapped all the non- 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 element, which meant that the original element was no longer required because its contents have been done away with. The original 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 contains an ordered series of metadata elements:

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 ) should cause heading text to be generated.

The element 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 has common attributes and a required href attribute.

The content model of 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 element was added unilaterally because it seemed like a generally good idea.

The 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 contains, in order, (optional), , and 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 has been parameterized so that a different form of date information can be supplied if necessary.

The element requires the variant of the 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 to contain was to give it a special subelement where 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 to allow it to contain and, in preparation for losing entirely, allowed inside . In other words, is obsolete and will be removed from future versions of the DTD.

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

Following are the members of the paragraph class:

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

The element is a special version of a paragraph (now obsolete) that was created to allow (see Section 5.4.2) inside it. A contains a mixture of one or more and/or .

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

These elements should be presented as vertically set off from other surrounding elements, and their content should be wrapped.

Originally, only was made available, and it contained . Dan requested that the element not be made generally available, because properly these should only occur in the status section of a technical report, and 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 anywhere else, and we added to regular paragraphs and to the status section.

The following are the members of the regular list class:

The element identifies unordered lists (for example, with items indicated with bullets) and the element identifies ordered lists (for example, with items indicated with arabic numbers). Both and contain one or more elements, which identifies a list item. An 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.

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

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

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 element was previously . The element was previously . The element type was split out to achieve greater content model control, and the names were chosen for consistency.

The element identifies a simple list, in which the items are presumed to contain only a small word or phrase. The contains one or more 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 and elements have two common attributes (see Chapter 2):

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.

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

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

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

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

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

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

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

The following are the members of the special list class:

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

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

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

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

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

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

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

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

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

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

The element also has the following semi-common attribute:

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.

The element was previously the element. The element was previously the element. The names were changed for consistency and clarity.

The following are the members of the note class:

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

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

Although this element type was originally , 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.

This was previously . 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.

The element identifies a well-formedness constraint note and the element identifies a validity constraint note. Both and contain, in order, a followed by one or more standalone elements (see Table 7-1)

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

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

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 or elements.

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

These elements were previously and . The elements were split out for greater content model and linking control.

The following are the members of the illustration class:

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

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

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

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.

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

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

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

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

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

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

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

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

The (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 does (see Table 7-2) .

The and elements are empty. These indications of constraints must each use their required def attribute to link to an actual or element that defines it.

The , , , , , , , , , , , and elements all have two common attributes (see Section 2.1):

In addition to the common attributes, Tthe and elements have the following semi-common attribute:

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

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

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 ) they define. The style of production we have been using involves the generated output of a LHS/RHS equivalence separator. Comments ( ) 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 and elements should generate text in place corresponding to either “WFC:” or “VC:”, followed by the head of the note they link to.

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 elements per to correspond to each display line.

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

The identifies an HTML-style table construct. It contains one or more table body elements ( ), which in turn contains one or more table rows ( ). The element contains one or more table cells ( ).

The element contains character data and phrase-level elements (see Table 7-2).

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

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

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

The element can have the same align and valign attributes that the element can have, except that the alignment values apply to the whole row, not just the cell.

The element should be handled as as HTML elements are handled in HTML browsers.

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.

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

The element is the only member of the annotation class.

The 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 mixture.

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

For print, the location of the 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 element.

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

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

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

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

This element exists mostly to allow control of the typographical emphasis, since the term attribute on 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 contains a term definition. 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 element). Note that because the element has mixed content, the presence of within it can't be guaranteed by means of a validating XML processor. However, there is an editorial expectation that will be present. (See issue 9 in Section 1.4.)

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

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

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.

The following are the members of the emphasized text class:

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

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

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

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 .

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

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

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

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 following are the members of the reference class:

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

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

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

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

This element is allowed in a wide variety of places because (as noted in issue 5 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.

The 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 element does. (Ideally, the content of the 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, elements should be avoided anywhere in a specification in favor of . See issue 5 in Section 1.4 for more information.

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

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

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 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 (division), an in an (numbered list item), or a (language production) in the current spec.

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

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

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

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

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 is that this one uses the ID/IDREF method of linking and 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 does.

The element identifies a mention of a term that is defined elsewhere; the mention also serves as a reference to the definition by linking to the element that defines the term (see Section 5.2.1). The 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 sectikon, it is more reasonable to mark up only the first occurrence of that term within the passage or section.

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

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

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

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

The 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 element is typically expected to be used inside the element, to supply the title of the work being identified in the bibliography entry. Note that both the element and the element can function as a hypertext link to the referenced resource; see issue 6 in Section 1.4.

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

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

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 6 in Section 1.4.

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

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

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

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

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

The 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 element in the other specification that defines the term (see Section 5.2.1). It contains character data (see Table 7-2).

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

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

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

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

The following are the members of the technical class:

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

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

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

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

The element contains a keyword in the language being described in the document. It contains a mixture of character data and phrase-level elements (see Table 7-2).

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

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 “ keyword”, might be appropriate.

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

The element is a mention of a nonterminal. It must link to the production that defines the nonterminal. It contains character data (see Table 7-2).

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

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

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 typically 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 element identifies a mention of a nonterminal whose production appears in another specification; the mention also serves as a reference to the production by linking to the element in the other specification that defines the term (see Section 4.5.3). It contains character data (see Table 7-2).

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

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

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

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

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

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

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

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.

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 need not be more complicated than because the note doesn't need to contribute to the “real” content of the document.

The following table shows the expected linking relationships among pieces of information using this DTD.

Currently, no non-SGML notations have been defined. See issue 8 in Section 1.4.

The following table summarizes the available character and symbol entities that are XML-compliant and currently available in the W3C DTD.

Following are the element classes and mixtures used in this DTD.

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

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 .

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

Table 7-2 shows the element mixtures built up out of “character data” (here standing for , 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.

Rights

Copyright to metadata belongs to Continuing Education Metadata Project.

Format

text/html; charset=unknown-8bit 145.37 KB

Language

en

Identifier

http://xml.coverpages.org/xmlspec-report-19980407.html

Files

Citation

Xml staff, “Design Report for the W3C XML Specification DTD,” Continuing Education on New Data Standards & Technologies, accessed March 19, 2019, http://acva2010.cs.drexel.edu/omeka/items/show/37423.