Table of contentsAppendices |
3.2 Element Type DeclarationsElement Type DeclarationsThe 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
where the Name gives the element type being declared. Validity Constraint: Unique Element Type Declaration Unique Element Type DeclarationAn 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 ContentAn 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
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 ( 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 NestingParameter-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 ( 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 ContentAn 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
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 TypesThe 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)> |