Stylus Studio XML Editor

Table of contents

Appendices

1.3 Documentation Conventions and Terminology

Documentation Conventions and Terminology

The section introduces the highlighting and typography as used in this document to present technical material.

Special terms are defined at their point of introduction in the text. For example a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance term.

Non-normative examples are set off in boxes and accompanied by a brief explanation:

NOTE: 
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">

And an explanation of the example.

The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:

[Documentation Conventions and Terminology]

References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance [xmpl-prop].

The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determine which of several different components may arise, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.

In the XML representation, bold-face attribute names (e.g. count below) indicate a required attribute information item, and the rest are optional. Where an attribute information item has an enumerated type definition, the values are shown separated by vertical bars, as for size below; if there is a default value, it is shown following a colon. Where an attribute information item has a built-in simple type definition defined in [ref-xsp2], a hyperlink to its definition therein is given.

The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ?, * and +. Each element name therein is a hyperlink to its own illustration.

NOTE: 

The illustrations are derived automatically from the [Schema for Schemas (normative)]. In the case of apparent conflict, the [Schema for Schemas (normative)] takes precedence, as it, together with the Schema Representation Constraint, provide the normative statement of the form of XML representations.

[Documentation Conventions and Terminology]

References to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance [example].

References to properties of information items as defined in [ref-xmlinfo] are notated as links to the relevant section thereof, set off with square brackets, for example [children].

Properties which this specification defines for information items are introduced as follows:

The value the property gets.

References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example [ex-foo].

The following highlighting is used for non-normative commentary in this document:

NOTE: 

General comments directed to all readers.

Following [ref-xml], within normative prose in this specification, the words may and must are defined as follows:

may

Conforming documents and XML Schema-aware processors are permitted to but need not behave as described.

must

Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.

Note however that this specification provides a definition of error and of conformant processors' responsibilities with respect to errors (see [Schemas and Schema-validity Assessment]) which is considerably more complex than that of [ref-xml].