Stylus Studio XML Editor

Table of contents

Appendices

3.2 Element Type Declarations

Element Type Declarations

The Element structure of an XML Document MAY, for Validity purposes, be constrained using element type and attribute-list declarations. An element type declaration constrains the element's Content.

Element type declarations often constrain which element types can appear as Parent/Child of the element. At user option, an XML processor MAY issue a warning when a declaration mentions an element type for which no declaration is provided, but this is not an error.

An element type declaration takes the form:

Element Type Declaration
3.2    elementdecl   ::=   '<!ELEMENT' S Name S contentspec S? '>'[VC: Unique Element Type Declaration]
3.2    contentspec   ::=   'EMPTY' | 'ANY' | Mixed | children

where the Name gives the element type being declared.

Validity Constraint: Unique Element Type Declaration

Unique Element Type Declaration

An element type MUST NOT be declared more than once.

Examples of element type declarations:

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

Element Content[top]

Element Content

An element Start-Tag has element content when elements of that type MUST contain only Parent/Child elements (no character data), optionally separated by white space (characters matching the nonterminal S). In this case, the constraint includes a content model, a simple grammar governing the allowed types of the child elements and the order in which they are allowed to appear. The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles:

Element-content Models
3.2.1    children   ::=   (choice | seq) ('?' | '*' | '+')?
3.2.1    cp   ::=   (Name | choice | seq) ('?' | '*' | '+')?
3.2.1    choice   ::=   '(' S? cp ( S? '|' S? cp )+ S? ')'[VC: Proper Group/PE Nesting]
3.2.1    seq   ::=   '(' S? cp ( S? ',' S? cp )* S? ')'[VC: Proper Group/PE Nesting]

where each Name is the type of an element which MAY appear as a Parent/Child. Any content particle in a choice list MAY appear in the Element content at the location where the choice list appears in the grammar; content particles occurring in a sequence list MUST each appear in the Element content in the order given in the list. The optional character following a name or list governs whether the element or the content particles in the list may occur one or more (+), zero or more (*), or zero or one times (?). The absence of such an operator means that the element or content particle MUST appear exactly once. This syntax and meaning are identical to those used in the productions in this specification.

The content of an element matches a content model if and only if it is possible to trace out a path through the content model, obeying the sequence, choice, and repetition operators and matching each element in the content against an element type in the content model. For Compatibility, it is an error if the content model allows an element to match more than one occurrence of an element type in the content model. For more information, see [Deterministic Content Models].

Validity Constraint: Proper Group/PE Nesting

Proper Group/PE Nesting

Parameter-entity Replacement Text MUST be properly nested with parenthesized groups. That is to say, if either of the opening or closing parentheses in a choice, seq, or Mixed construct is contained in the replacement text for a Parameter-entity reference, both MUST be contained in the same replacement text.

For interoperability, if a parameter-entity reference appears in a choice, seq, or Mixed construct, its replacement text SHOULD contain at least one non-blank character, and neither the first nor last non-blank character of the replacement text SHOULD be a connector (| or ,).

Examples of element-content models:

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

Mixed Content[top]

Mixed Content

An element Start-Tag has mixed content when elements of that type MAY contain character data, optionally interspersed with Parent/Child elements. In this case, the types of the child elements MAY be constrained, but not their order or their number of occurrences:

Mixed-content Declaration
3.2.2    Mixed   ::=   '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
| '(' S? '#PCDATA' S? ')' [VC: Proper Group/PE Nesting]
[VC: No Duplicate Types]

where the Names give the types of elements that may appear as children. The keyword #PCDATA derives historically from the term "parsed character data."

Validity Constraint: No Duplicate Types

No Duplicate Types

The same name MUST NOT appear more than once in a single mixed-content declaration.

Examples of mixed content declarations:

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>