RELAX NG Specification

Committee Specification�11 August 2001

This version:
Committee Specification: 11 August 2001
Editors:
James Clark�<jjc@jclark.com>, MURATA Makoto�<mura034@attglobal.net>

Copyright � The Organization for the Advancement of Structured Information Standards [OASIS] 2001. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Abstract

This is the definitive specification of RELAX NG, a simple schema language for XML, based on [RELAX] and [TREX]. A RELAX NG schema specifies a pattern for the structure and content of an XML document. A RELAX NG schema is itself an XML document.

Status of this Document

This committee specification was approved for publication by the OASIS RELAX NG technical committee. It is a stable document which the committee believes is now ready for implementation. This specification is for version 0.9 of RELAX NG. The committee invites comments on this specification from both users and implementors until 10th October 2001. Comments should be sent to relax-ng-comment@lists.oasis-open.org. Feedback on the issues described in Appendix B. Issues is particularly welcome. At the end of the comment period, the committee plans to consider the comments received, resolve all outstanding issues and release a specification for version 1.0 of RELAX NG.

Table of Contents

1 Introduction
2 Data model
2.1 Example
3 Full syntax
3.1 Example
4 Simplification
4.1 Annotations
4.2 Whitespace
4.3 datatypeLibrary attribute
4.4 type attribute of value element
4.5 href attribute
4.6 externalRef element
4.7 include element
4.8 name attribute of element and attribute elements
4.9 ns attribute
4.10 QNames
4.11 div element
4.12 Number of child elements
4.13 mixed element
4.14 optional element
4.15 zeroOrMore element
4.16 combine attribute
4.17 grammar element
4.18 define and ref elements
4.19 notAllowed element
4.20 empty element
5 Simple syntax
5.1 Example
6 Semantics
6.1 Name classes
6.2 Patterns
6.2.1 choice pattern
6.2.2 group pattern
6.2.3 empty pattern
6.2.4 text pattern
6.2.5 oneOrMore pattern
6.2.6 interleave pattern
6.2.7 attribute pattern
6.2.8 element pattern
6.2.9 data and value pattern
6.2.10 Builtin datatype library
6.2.11 list pattern
6.3 Validity
6.4 Example
7 Restrictions
7.1 Contextual restrictions
7.1.1 attribute pattern
7.1.2 oneOrMore pattern
7.1.3 list pattern
7.1.4 except in data pattern
7.1.5 start element
7.1.6 except in name classes
7.2 String sequences
7.3 Duplicate attributes
8 Conformance

Appendixes

A RELAX NG schema for RELAX NG
B Issues
B.1 Interleave
B.2 References to named patterns in external grammars
C RELAX NG TC (Non-Normative)
References

1. Introduction

This document specifies

  • when an XML document is a correct RELAX NG schema
  • when an XML document is valid with respect to a correct RELAX NG schema.

An XML document that is being validated with respect to a RELAX NG schema is referred to as an instance.

The structure of this document is as follows. Section 2 describes the data model, which is the abstraction of an XML document used throughout the rest of the document. Section 3 describes the syntax of a RELAX NG schema; any correct RELAX NG schema must conform to this syntax. Section 4 describes a sequence of transformations that are applied to simplify a RELAX NG schema; applying the transformations also involves checking certain restrictions that must be satisfied by a correct RELAX NG schema. Section 5 describes the syntax that results from applying the transformations; this simple syntax is a subset of the full syntax. Section 6 describes the semantics of a correct RELAX NG schema that uses the simple syntax; the semantics specify when an element is valid with respect to a RELAX NG schema. Section 7 describes restrictions in terms of the simple syntax; a correct RELAX NG schema must be such that, after transformation into the simple form, it satisfies these restrictions. Finally, Section 8 describes conformance requirements for RELAX NG validators.

2. Data model

RELAX NG deals with XML documents representing both schemas and instances through an abstract data model. XML documents representing schemas and instances must be well-formed in conformance with [XML 1.0] and must conform to the constraints of [XML Namespaces].

An XML document is represented by an element. An element consists of

  • a name
  • a context
  • a set of attributes
  • an ordered sequence of zero or more children; each child is either an element or a non-empty string; the sequence never contains two consecutive strings

A name consists of

  • a string representing the namespace URI; the empty string has special significance, representing the absence of any namespace
  • a string representing the local name; this string matches the NCName production of [XML Namespaces]

A context consists of

  • a base URI
  • a namespace map; this maps prefixes to namespace URIs, and also may specify a default namespace URI (as declared by the xmlns attribute)

An attribute consists of

  • a name
  • a string representing the value

A string consists of a sequence of zero or more characters, where a character is as defined in [XML 1.0].

The element for an XML document is constructed from an instance of the [XML Infoset] as follows. We use the notation [x] to refer to the value of the x property of an information item. An element is constructed from a document information item by constructing an element from the [document element]. An element is constructed from an element information item by constructing the name from the [namespace name] and [local name], the context from the [base URI] and [in-scope namespaces], the attributes from the [attributes], and the children from the [children]. The attributes of an element are constructed from the unordered set of attribute information items by constructing an attribute for each attribute information item. The children of an element are constructed from the list of child information items first by removing information items other than element information items and character information items, and then by constructing an element for each element information item in the list and a string for each maximal sequence of character information items. An attribute is constructed from an attribute information item by constructing the name from the [namespace name] and [local name], and the value from the [normalized value]. When constructing the name of an element or attribute from the [namespace name] and [local name], if the [namespace name] property is not present, then the name is constructed from an empty string and the [local name]. A string is constructed from a sequence of character information items by constructing a character from the [character code] of each character information item.

It is possible for there to be multiple distinct infosets for a single XML document. This is because XML parsers are not required to process all DTD declarations or expand all external parsed general entities. Amongst these multiple infosets, there is exactly one infoset for which [all declarations processed] is true and which does not contain any unexpanded entity reference information items. This is the infoset that is the basis for defining the RELAX NG data model.

2.1. Example

Suppose the document http://www.example.com/doc.xml is as follows:

<?xml version="1.0"?>
<foo><pre1:bar1 xmlns:pre1="http://www.example.com/n1"/><pre2:bar2
  xmlns:pre2="http://www.example.com/n2"/></foo>

The element representing this document has

  • a name which has
    • the empty string as the namespace URI, representing the absence of any namespace
    • foo as the local name
  • a context which has
    • http://www.example.com/doc.xml as the base URI
    • a namespace map which
      • maps the prefix xml to the namespace URI http://www.w3.org/XML/1998/namespace (the xml prefix is implicitly declared by every XML document)
      • specifies the empty string as the default namespace URI
  • an empty set of attributes
  • a sequence of children consisting of an element which has
    • a name which has
      • http://www.example.com/n1 as the namespace URI
      • bar1 as the local name
    • a context which has
      • http://www.example.com/doc.xml as the base URI
      • a namespace map which
        • maps the prefix pre1 to the namespace URI http://www.example.com/n1
        • maps the prefix xml to the namespace URI http://www.w3.org/XML/1998/namespace
        • specifies the empty string as the default namespace URI
    • an empty set of attributes
    • an empty sequence of children

    followed by an element which has

    • a name which has
      • http://www.example.com/n2 as the namespace URI
      • bar2 as the local name
    • a context which has
      • http://www.example.com/doc.xml as the base URI
      • a namespace map which
        • maps the prefix pre2 to the namespace URI http://www.example.com/n2
        • maps the prefix xml to the namespace URI http://www.w3.org/XML/1998/namespace
        • specifies the empty string as the default namespace URI
    • an empty set of attributes
    • an empty sequence of children

3. Full syntax

The following grammar summarizes the syntax of RELAX NG. Although we use a notation based on the XML representation of an RELAX NG schema as a sequence of characters, the grammar must be understood as operating at the data model level. For example, although the syntax uses <text/>, an instance or schema can use <text></text> instead, because they both represent the same element at the data model level. All elements shown in the grammar are qualified with the namespace URI:

http://relaxng.org/ns/structure/0.9

The symbols QName and NCName are defined in [XML Namespaces]. The anyURI symbol has the same meaning as the anyURI datatype of [W3C XML Schema Datatypes]: it indicates a string that, after escaping of disallowed values as described in Section 5.4 of [XLink], is a URI reference as defined in [RFC 2396] (as modified by [RFC 2732]). The symbol string matches any string.

In addition to the attributes shown explicitly, any element can have an ns attribute and any element can have a datatypeLibrary attribute. The value of these attributes must match the anyURI symbol as described in the previous paragraph. In addition, the value of these attributes must not use the relative form of URI reference, and, in the case of datatypeLibrary, must not have a fragment identifier.

Any element can also have foreign attributes in addition to the attributes shown in the grammar. A foreign attribute is an attribute with a name whose namespace URI is neither the empty string nor the RELAX NG namespace URI. Any element that cannot have string children (i.e. any element other than value and param) may have foreign child elements in addition to the child elements shown in the grammar. A foreign element is an element with a name whose namespace URI is not the RELAX NG namespace URI. There are no constraints on the relative position of foreign child elements with respect to other child elements.

Any element can also have as children strings that consist entirely of whitespace characters, where a whitespace character is one of #x20, #x9, #xD or #xA. There are no constraints on the relative position of whitespace string children with respect to child elements.

Leading and trailing whitespace is allowed for value of each name, type and combine attribute and for the content of each name element.

pattern��::=��<element name="QName"> pattern+ </element>
| <element> nameClass pattern+ </element>
| <attribute name="QName"> [pattern] </attribute>
| <attribute> nameClass [pattern] </attribute>
| <group> pattern+ </group>
| <interleave> pattern+ </interleave>
| <choice> pattern+ </choice>
| <optional> pattern+ </optional>
| <zeroOrMore> pattern+ </zeroOrMore>
| <oneOrMore> pattern+ </oneOrMore>
| <list> pattern+ </list>
| <mixed> pattern+ </mixed>
| <ref name="NCName"/>
| <parentRef name="NCName"/>
| <empty/>
| <text/>
| <value [type="NCName"]> string </value>
| <data type="NCName"> param* [exceptPattern] </data>
| <notAllowed/>
| <externalRef href="anyURI"/>
| <grammar> grammarContent* </grammar>
param��::=��<param name="NCName"> string </param>
exceptPattern��::=��<except> pattern+ </except>
grammarContent��::=��start
| define
| <div> grammarContent* </div>
| <include href="anyURI"> includeContent* </include>
includeContent��::=��start
| define
| <div> includeContent* </div>
start��::=��<start [combine="method"]> pattern </start>
define��::=��<define name="NCName" [combine="method"]> pattern+ </define>
method��::=��choice
| interleave
nameClass��::=��<name> QName </name>
| <anyName> [exceptNameClass] </anyName>
| <nsName> [exceptNameClass] </nsName>
| <choice> nameClass+ </choice>
exceptNameClass��::=��<except> nameClass+ </except>

3.1. Example

Here is an example of a schema in the full syntax for the document in Section 2.1.

<?xml version="1.0"?>
<element name="foo"
         xmlns="http://relaxng.org/ns/structure/0.9"
         xmlns:a="http://relaxng.org/ns/annotation/0.9"
         xmlns:ex1="http://www.example.com/n1"
         xmlns:ex2="http://www.example.com/n2">
  <a:documentation>A foo element.</a:document>
  <element name="ex1:bar1">
    <empty/>
  </element>
  <element name="ex2:bar2">
    <empty/>
  </element>
</element>

4. Simplification

The full syntax given in the previous section is transformed into a simpler syntax by applying the following transformation rules in order. The effect must be as if each rule was applied to all elements in the schema before the next rule is applied. A transformation rule may also specify constraints that must be satisfied by a correct schema. The transformation rules are applied at the data model level. Before the transformations are applied, the schema is parsed into an instance of the data model.

4.1. Annotations

Foreign attributes and elements are removed.

Note

It is safe to remove xml:base attributes at this stage because xml:base attributes are used in determining the [base URI] of an element information item, which is in turn used to construct the base URI of the context of an element. Thus, after a document has been parsed into an instance of the data model, xml:base attributes can be discarded.

4.2. Whitespace

For each element other than value and param, each child that is a string containing only whitespace characters is removed.

Leading and trailing whitespace characters are removed from the value of each name, type and combine attribute and from the content of each name element.

4.3. datatypeLibrary attribute

The value of each datatypeLibary attribute is transformed by escaping disallowed characters as specified in Section 5.4 of [XLink].

For any data or value element that does not have a datatypeLibrary attribute, a datatypeLibrary attribute is added. The value of the added datatypeLibrary attribute is the value of the datatypeLibrary attribute of the nearest ancestor element that has a datatypeLibrary attribute, or the empty string if there is no such ancestor. Then, any datatypeLibrary attribute that is on an element other than data or value is removed.

4.4. type attribute of value element

For any value element that does not have a type attribute, a type attribute is added with value token and the value of the datatypeLibrary attribute is changed to the empty string.

4.5. href attribute

The value of the href attribute on an externalRef or include element is first transformed by escaping disallowed characters as specified in Section 5.4 of [XLink]. The URI reference is then resolved into an absolute form as described in section 5.2 of [RFC 2396] using the base URI from the context of the element that bears the href attribute.

The value of the href attribute will be used to construct an element (as specified in Section 2). This must be done as follows. The URI reference consists of the URI itself and an optional fragment identifier. The resource identified by the URI is retrieved. The result is a MIME entity: a sequence of bytes labelled with a MIME media type. The media type determines how an element is constructed from the MIME entity and optional fragment identifier. When the media type is application/xml or text/xml, the MIME entity must be parsed as an XML document in accordance with the applicable RFC (at the term of writing [RFC 3023]) and an element constructed from the result of the parse as specified in Section 2. In particular, the charset parameter must be handled as specified by the RFC. This specification does not define the handling of media types other than application/xml and text/xml. The href attribute must not include a fragment identifier unless the registration of the media type of the resource identified by the attribute defines the interpretation of fragment identifiers for that media type.

Note

[RFC 3023] does not define the interpretation of fragment identifiers for application/xml or text/xml.

4.6. externalRef element

An externalRef element is transformed as follows. An element is constructed using the URI reference that is the value of href attribute as specified in Section 4.5. This element must match the syntax for pattern. The element is transformed by recursively applying the rules from this subsection and from previous subsections of this section. This must not result in a loop. In other words, the transformation of the referenced element must not require the dereferencing of an externalRef attribute with an href attribute with the same value.

Any ns attribute on the externalRef element is transferred to the referenced element if the referenced element does not already have an ns attribute. The externalRef element is then replaced by the referenced element.

4.7. include element

An include element is transformed as follows. An element is constructed using the URI reference that is the value of href attribute as specified in Section 4.5. This element must be a grammar element, matching the syntax for grammar.

This grammar element is transformed by recursively applying the rules from this subsection and from previous subsections of this section. This must not result in a loop. In other words, the transformation of the grammar element must not require the dereferencing of an include attribute with an href attribute with the same value.

Define the components of an element to be the children of the element together with the components of any div child elements. If the include element has a start component, then the grammar element must have a start component. If the include element has a start component, then all start components are removed from the grammar element. If the include element has a define component, then the grammar element must have a define component with the same name. For every define component of the include element, all define components with the same name are removed from the grammar element.

The include element is transformed into a div element. The attributes of the div element are the attributes of the include element other than the href attribute. The children of the div element are the grammar element (after the removal of the start and define components described by the preceding paragraph) followed by the children of the include element. The grammar element is then renamed to div.

4.8. name attribute of element and attribute elements

The name attribute on an element or attribute element is transformed into a name child element.

If an attribute element has a name attribute but no ns attribute, then an ns="" attribute is added to the name child element.

4.9. ns attribute

For any name, nsName or value element that does not have an ns attribute, an ns attribute is added. The value of the added ns attribute is the value of the ns attribute of the nearest ancestor element that has an ns attribute, or the empty string if there is no such ancestor. Then, any ns attribute that is on an element other than name, nsName or value is removed.

Note

The value of the ns attribute is not transformed either by escaping disallowed characters, or in any other way, because the value of the ns attribute is compared against namespace URIs in the instance, which are not subject to any transformation.

4.10. QNames

For any name element containing a prefix, the prefix is removed and an ns attribute is added replacing any existing ns attribute. The value of the added ns attribute is the value to which the prefix is mapped by the namespace map of the context of the name element. The context must have a mapping for the prefix.

4.11. div element

Each div element is replaced by its children.

4.12. Number of child elements

A define, oneOrMore, zeroOrMore, optional or mixed element is transformed so that it has exactly one child element. If it has more than one child element, then its child elements are wrapped in a group element. Similarly, an element is transformed so that it has exactly two child elements, the first being a name class and the second being a pattern. If it has more than two child element, then the child elements other than the first are wrapped in a group element.

A except element is transformed so that it has exactly one child element. If it has more than one child element, then its child elements are wrapped in a choice element.

If an attribute element has only one child element (a name class), then a text element is added.

A choice, group or interleave element is transformed so that it has exactly two child elements. If it has one child element, then it is replaced by its child element. If it has more than two child elements, then the first two child elements are combined into a new element with the same name as the parent element and with the first two child elements as its children. For example,

<choice> p1 p2 p3 </choice>

is transformed to

<choice> <choice> p1 p2 </choice> p3 </choice>

This reduces the number of child elements by one. The transformation is applied repeatedly until it has exactly two child elements.

4.13. mixed element

A mixed element is transformed into an interleaving with a text element:

<mixed> p </mixed>

is transformed into

<interleave> p <text/> </interleave>

4.14. optional element

An optional element is transformed into a choice with empty:

<optional> p </optional>

is transformed into

<choice> p <empty/> </choice>

4.15. zeroOrMore element

A zeroOrMore element is transformed into a choice between oneOrMore and empty:

<zeroOrMore> p </zeroOrMore>

is transformed into

<choice> <oneOrMore> p </oneOrMore> <empty/> </choice>

4.16. combine attribute

For each grammar element, all define elements with the same name are combined together. For any name, there must not be more than one define element with that name that does not have a combine attribute. For any name, if there is a define element with that name that has a combine attribute with the value choice, then there must not also be a define element with that name that has a combine attribute with the value interleave. Thus, for any name, if there is more than one define element with that name, then there is a unique value for the combine attribute for that name. After determining this unique value, the combine attributes are removed. A pair of definitions

<define name="n">
  p1
</define>
<define name="n">
  p2
</define>

is combined into

<define name="n">
  <c>
    p1
    p2
  </c>
</define>

where c is the value of the combine attribute. Pairs of definitions are combined until there is exactly one define element for each name.

Similarly, for each grammar element all start elements are combined together. There must not be more than one start element that does not have a combine attribute. If there is a start element that has a combine attribute with the value choice, there must not also be a start element that has a combine attribute with the value interleave.

4.17. grammar element

In this rule, the schema is transformed so that its top-level element is grammar and so that it has no other grammar elements.

Define the in-scope grammar for an element be the nearest ancestor grammar element. A ref element refers to a define element if the value of their name attributes is the same and their in-scope grammars are the same. A parentRef element refers to a define element if the value of their name attributes is the same and the in-scope grammar of the in-scope grammar of the parentRef element is the same as the in-scope grammar of the define element. Every ref or parentRef element must refer to a define element. A grammar must have a start child element.

First, transform the top-level pattern p into <grammar><start>p</start></grammar>. Next, rename define elements so that no two define elements anywhere in the schema have the same name. To rename a define element, change the value of its name attribute and change the value of the name attribute of all ref and parentRef elements that refer to that define element. Next, move all define elements to be children of the top-level grammar element, replace each nested grammar element by the child of its start element and rename each parentRef element to ref.

4.18. define and ref elements

In this rule, the grammar is transformed so that every element element is the child of a define element, and the child of every define element is an element element.

First, remove any define element which does not have any ref element referring to it. Now, for each element element that is not the child of a define element, add a define element to the grammar element, and replace the element element by a ref element referring to the added define element. The value of the name attribute of the added define element must be different from value of the name attribute of all other define elements. The child of the added define element is the element element.

Define a ref element to be expandable if it refers to a define element whose child is not an element element. For each ref element that is expandable and is a descendant of a start element or an element element, expand it by replacing the ref element by the child of the define element to which it refers and then recursively expanding any expandable ref elements in this replacement. This must not result in a loop. In other words expanding the replacement of a ref element having a name with value n must not require the expansion of ref element also having a name with value n. Finally, remove any define element whose child is not an element element.

4.19. notAllowed element

In this rule, the grammar is transformed so that a notAllowed element occurs only as the child of a start or element element. A attribute, list, group, interleave, or oneOrMore element that has a notAllowed child element is transformed into a notAllowed element. A choice element that has two notAllowed child elements is transformed into a notAllowed element. A choice element that has one notAllowed child element is transformed into its other child element. The preceding transformations are applied repeatedly until none of them is applicable any more.

4.20. empty element

In this rule, the grammar is transformed so that an empty element does not occur as a child of a group, interleave, or oneOrMore element or as the second child of a choice element. A group, interleave or choice element that has two empty child elements is transformed into an empty element. A group or interleave element that has one empty child element is transformed into its other child element. A choice element whose second child element is an empty element is transformed by interchanging its two child elements. A oneOrMore element that has an empty child element is transformed into an empty element. The preceding transformations are applied repeatedly until none of them is applicable any more.

5. Simple syntax

After applying all the rules in Section 4, the schema will match the following grammar:

grammar��::=��<grammar> <start> top </start> define* </grammar>
define��::=��<define name="NCName"> <element> nameClass top </element> </define>
top��::=��<notAllowed/>
| pattern
pattern��::=��<empty/>
| nonEmptyPattern
nonEmptyPattern��::=��<text/>
| <data type="NCName" datatypeLibrary="anyURI"> param* [exceptPattern] </data>
| <value datatypeLibrary="anyURI" type="NCName" ns="anyURI"> string </value>
| <list> pattern </list>
| <attribute> nameClass pattern </attribute>
| <ref name="NCName"/>
| <oneOrMore> nonEmptyPattern </oneOrMore>
| <choice> pattern nonEmptyPattern </choice>
| <group> nonEmptyPattern nonEmptyPattern </group>
| <interleave> nonEmptyPattern nonEmptyPattern </interleave>
param��::=��<param name="NCName"> string </param>
exceptPattern��::=��<except> pattern </except>
nameClass��::=��<anyName> [exceptNameClass] </anyName>
| <nsName ns="anyURI"> [exceptNameClass] </nsName>
| <name ns="anyURI"> NCName </name>
| <choice> nameClass nameClass </choice>
exceptNameClass��::=��<except> nameClass </except>

With this grammar, no elements or attributes are allowed other than those explicitly shown.

5.1. Example

The following is an example of how the schema in Section 3.1 can be transformed into the simple syntax:

<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/0.9">
  <start>
    <ref name="foo.element"/>
  </start>

  <define name="foo.element">
    <element>
      <name ns="">foo</name>
      <group>
        <ref name="bar1.element"/>
        <ref name="bar2.element"/>
      </group>
    </element>
  </define>

  <define name="bar1.element">
    <element>
      <name ns="http://www.example.com/n1">bar1</name>
      <empty/>
    </element>
  </define>

  <define name="bar2.element">
    <element>
      <name ns="http://www.example.com/n2">bar2</name>
      <empty/>
    </element>
  </define>
</grammar>

Note

Strictly speaking, the result of simplification is instance of the data model rather than an XML document. For convenience, we use an XML document to represent an instance of the data model.

6. Semantics

In this section, we define the semantics of a correct RELAX NG schema that has been transformed into the simple syntax. The semantics of a RELAX NG schema consist of a specification of what XML documents are valid with respect to that schema. The semantics are described formally as a proof system. A proof system consists of axioms and inference rules. Axioms are propositions that are provable unconditionally. An inference rule consists of one or more antecedents and exactly one consequent. If the antecedents of an inference rule are all provable, then the consequent of the inference rule is also provable. An XML document is valid with respect to a RELAX NG schema if and only if the proposition that it is valid is provable in the proof system described in this section.

The notation for inference rules separates the antecedents from the consequent by a horizontal line: the antecedents are above the line; the consequent is below the line. Both axioms and inferences rules may use variables. A variable has a name and optionally a subscript. The name of a variable is italicized. Each variable has a range that is determined by its name. Axioms and inference rules are implicitly universally quantified over the variables they contain. We explain this further below.

The possibility that an inference rule or axiom may contain more than one occurrence of a particular variable requires that an identity relation be defined on each kind of object over which a variable can range. The identity relation for all kinds of object is value-based. Two objects of a particular kind are identical if the constituents of the objects are identical. For example, two attributes are considered the same if they have the same name and the same value. Two characters are identical if their Unicode character codes are the same.

6.1. Name classes

The main semantic concept for name classes is that of a name belonging to a name class. A name class is an element that matches the production nameClass. A name is as defined in Section 2: it consists of a namespace URI and a local name.

We use the following notation:

n
is a variable that ranges over names
nc
ranges over name classes
n in nc
asserts that name n is a member of name class nc

We are now ready for our first axiom, which is called "anyName 1":

(anyName 1)
n in <anyName/>

This says for any name n, n belongs to the name class <anyName/>, in other words <anyName/> matches any name. Note the effect of the implicit universal quantification over the variables in the axiom: this is what makes the axiom apply for any name n.

Our first inference rule is almost as simple:

(anyName 2)
not(n in nc)

n in <anyName> <except> nc </except> </anyName>

This says that for any name n and for any name class nc, if n does not belong to nc, then n belongs to <anyName> <except> nc </except> </anyName>. In other words, <anyName> <except> nc </except> </anyName> matches any name that does not match nc.

We now need the following additional notation:

ln
ranges over local names (NCNames, names without prefixes)
u
ranges over URIs
name( u, ln )
constructs a name with URI u and local name ln

The remaining axioms and inference rules for name classes are as follows:

(nsName 1)
name( u, ln ) in <nsName ns="u"/>
(nsName 2)
not(name( u, ln ) in nc)

name( u, ln ) in <nsName ns="u"> <except> nc </except> </nsName>
(name)
name( u, ln ) in <name ns="u"> ln </name>
(name choice 1)
n in nc1

n in <choice> nc1 nc2 </choice>
(name choice 2)
n in nc2

n in <choice> nc1 nc2 </choice>

6.2. Patterns

The axioms and inference rules for patterns use the following notation:

cx
ranges over contexts (as defined in Section 2)
a
ranges over sets of attributes; a set with a single member is considered the same as that member
m
ranges over sequences of elements and strings; a sequence with a single member is considered the same as that member; the sequences ranged over by m may contain consecutive strings and may contain strings that are empty; thus, there are sequences ranged over by m that cannot occur as the children of an element
p
ranges over patterns (elements matching the pattern production)
cx |- a; m =~ p
asserts that with respect to context cx, the attributes a and the sequence of elements and strings m matches the pattern p

6.2.1. choice pattern

The semantics of the choice pattern are as follows:

(choice 1)
cx |- a; m =~ p1

cx |- a; m =~ <choice> p1 p2 </choice>
(choice 2)
cx |- a; m =~ p2

cx |- a; m =~ <choice> p1 p2 </choice>

6.2.2. group pattern

We use the following additional notation:

m1, m2
represents the concatenation of the sequences m1 and m2
a1 + a2
represents the union of a1 and a2

The semantics of the group pattern are as follows:

(group)
cx |- a1; m1 =~ p1����cx |- a2; m2 =~ p2

cx |- a1 + a2; m1, m2 =~ <group> p1 p2 </group>

Note

The restriction in Section 7.3 ensures that the set of attributes constructed in the consequent will not have multiple attributes with the same name.

6.2.3. empty pattern

We use the following additional notation:

( )
represents an empty sequence
{ }
represents an empty set

The semantics of the empty pattern are as follows:

(empty)
cx |- { }; ( ) =~ <empty/>

6.2.4. text pattern

We use the following additional notation:

s
ranges over strings

The semantics of the text pattern are as follows:

(text 1)
cx |- { }; s =~ <text/>
(text 2)
cx |- { }; m =~ <text/>

cx |- { }; m, s =~ <text/>

The effect of the above rule is that a text element matches zero or more strings.

6.2.5. oneOrMore pattern

We use the following additional notation:

disjoint(a1, a2)
asserts that there is no name that is the name of both an attribute in a1 and of an attribute in a2

The semantics of the oneOrMore pattern are as follows:

(oneOrMore 1)
cx |- a; m =~ p

cx |- a; m =~ <oneOrMore> p </oneOrMore>
(oneOrMore 2)
cx |- a1; m1 =~ p����cx |- a2; m2 =~ <oneOrMore> p </oneOrMore>����disjoint(a1, a2)

cx |- a1 + a2; m1, m2 =~ <oneOrMore> p </oneOrMore>

6.2.6. interleave pattern

We use the following additional notation:

m1 interleaves m2; m3
asserts that m1 is an interleaving of m2 and m3

The semantics of interleaving are defined by the following rules.

(interleaves 1)
( ) interleaves ( ); ( )
(interleaves 2)
m1 interleaves m2; m3

m4, m1 interleaves m4, m2; m3
(interleaves 3)
m1 interleaves m2; m3

m4, m1 interleaves m2; m4, m3

For example, the interleavings of <a/><a/> and <b/> are <a/><a/><b/>, <a/><b/><a/>, and <b/><a/><a/>.

The semantics of the interleave pattern are as follows:

(interleave)
cx |- a1; m1 =~ p1����cx |- a2; m2 =~ p2����m3 interleaves m1; m2

cx |- a1 + a2; m3 =~ <interleave> p1 p2 </interleave>

Note

The restriction in Section 7.3 ensures that the set of attributes constructed in the consequent will not have multiple attributes with the same name.

6.2.7. attribute pattern

We use the following additional notation:

v
ranges over strings and the empty sequence; this is a subset of the range of m
toString( v )
returns an empty string if v is the empty sequence and otherwise returns v
attribute( n, s )
constructs an attribute with name n and value s

The semantics of the attribute pattern are as follows:

(attribute)
cx |- { }; v =~ p����n in nc

cx |- attribute( n, toString( v ) ); ( ) =~ <attribute> nc p </attribute>

Note

The value of an attribute is always a single string, which may be empty. Thus, the empty sequence is not a possible attribute value. On the hand, the children of an element can be an empty sequence and cannot consist of an empty string. The toString function in the above inference rule ensures that validation handles attributes and elements uniformly by converting empty sequences to empty strings.

6.2.8. element pattern

We use the following additional notation:

okAsChildren(m)
asserts that the mixed sequence m can occur as the children of an element: it does not contain any member that is an empty string, nor does it contain two consecutive members that are both strings
element( n, cx, a, m )
constructs an element with name n, context cx, attributes a and mixed sequence m as children
stripSpace( m )
returns the sequence m after removing any member that is a string consisting entirely of whitespace
deref(ln) = <element> nc p </element>
asserts that the grammar contains <define name="ln"> <element> nc p </element> </define>

The semantics of the element pattern are as follows:

(element)
cx1 |- a; stripSpace( m ) =~ p����n in nc����okAsChildren(m)����deref(ln) = <element> nc p </element>

cx2 |- { }; element( n, cx1, a, m ) =~ <ref name="ln"/>

6.2.9. data and value pattern

RELAX NG relies on datatype libraries to perform datatyping. A datatype library is identified by a URI. A datatype within a datatype library is identified by a NCName. A datatype library provides two services.

  • It can determine whether a string is a legal representation of a datatype. This service accepts an list of zero or more parameters. For example, a string datatype might have a parameter specifying the length of a string. The datatype library determines what parameters are applicable for each datatype.
  • It can determine whether two strings represent the same value of a datatype. This service does not have any parameters.

Both services may make use of the context of a string. For example, a datatype representing a QName would use the namespace map.

We use the following additional notation:

datatypeAllows(u, ln, params, s, cx)
asserts that in the datatype library identified by URI u, the string s interpreted with context cx is a legal value of datatype ln with parameters params
datatypeEqual(u, ln, s1, cx1, s2, cx2)
asserts that in the datatype library identified by URI u, string s1 interpreted with context cx1 represents the same value of the datatype ln as the string s2 interpreted in the context of cx2
params
ranges over sequences of parameters
[cx]
within the start-tag of a pattern refers to the context of the pattern element
""
represents an empty string
context( u, cx )
constructs a context which is the same as cx except that the default namespace is u; if u is the empty string, then there is no default namespace in the constructed context

The datatypeEqual function must be reflexive, transitive and symmetric, that is the following inference rules must hold:

(datatypeEqual reflexive)
datatypeAllows(u, ln, params, s, cx)

datatypeEqual(u, ln, s, cx, s, cx)
(datatypeEqual transitive)
datatypeEqual(u, ln, s1, cx1, s2, cx2)����datatypeEqual(u, ln, s2, cx3, s3, cx3)

datatypeEqual(u, ln, s1, cx1, s3, cx3)
(datatypeEqual symmetric)
datatypeEqual(u, ln, s1, cx1, s2, cx2)

datatypeEqual(u, ln, s2, cx2, s1, cx1)

The semantics of the data and value patterns are as follows:

(value)
datatypeEqual(u1, ln, s1, cx1, s2, context( u2, cx2 ))

cx1 |- { }; s1 =~ <value datatypeLibrary="u1" type="ln" ns="u2" [cx2]> s2 </value>
(data 1)
datatypeAllows(u, ln, params, s, cx)

cx |- { }; s =~ <data datatypeLibrary="u" type="ln"> params </data>
(data 2)
datatypeAllows(u, ln, params, s, cx)����not(cx |- a; s =~ p)

cx |- { }; s =~ <data datatypeLibrary="u" type="ln"> params <except> p </except> </data>
(empty string)
cx |- { }; "" =~ p

cx |- { }; ( ) =~ p

Note

In the data model, an empty element such as <foo></foo> will have an empty sequence as its children, whereas an empty attribute such as occurs in <foo bar=""></foo> will have an empty string as its value. The "empty string" inference rule ensures that if a datatype allows an empty string and so matches the value of an empty attribute, then it will also match the content of an empty element.

6.2.10. Builtin datatype library

The empty URI identifies a special builtin datatype library. This provides two datatypes, string and token. No parameters are allowed for either of these datatypes.

s1 = s2
asserts that s1 and s2 are identical
normalizeWhiteSpace( s )
returns the string s, with leading and trailing whitespace characters removed, and with each other maximal sequence of whitespace characters replaced by a single space character

The semantics of the two builtin datatypes are as follows:

(string allows)
datatypeAllows("", "string", ( ), s, cx)
(string equal)
datatypeEqual("", "string", s, cx1, s, cx2)
(token allows)
datatypeAllows("", "token", ( ), s, cx)
(token equal)
normalizeWhiteSpace( s1 ) = normalizeWhiteSpace( s2 )

datatypeEqual("", "token", s1, cx1, s2, cx2)

6.2.11. list pattern

We use the following additional notation:

split( s )
returns a sequence of strings one for each whitespace delimited token of s; each string in the returned sequence will be non-empty and will not contain any whitespace

The semantics of the list pattern are as follows:

(list)
cx |- { }; split( s ) =~ p

cx |- { }; s =~ <list> p </list>

Note

It is crucial in the above inference rule that the sequence that is matched against a pattern can contain consecutive strings.

6.3. Validity

Now we can define when an element is valid with respect to a schema. We use the following additional notation:

e
ranges over elements
valid(e)
asserts that the element e is valid with respect to the grammar
start() = p
asserts that the grammar contains <start> p </start>

An element is valid if together with an empty set of attributes it matches the start pattern of the grammar.

(valid)
start() = p����cx |- { }; e =~ p

valid(e)

6.4. Example

Let e0 be

element( name( "", "foo" ), cx0, { }, m )

where m is

e1, e2

and e1 is

element( name( "http://www.example.com/n1", "bar1" ), cx1, { }, ( ) )

and e2 is

element( name( "http://www.example.com/n2", "bar2" ), cx2, { }, ( ) )

Assuming appropriate definitions of of cx0, cx1 and cx2, this represents the document in Section 2.1.

We now show how e0 can be shown to be valid with respect to the schema in Section 5.1. The schema is equivalent to the following propositions:

start() = <ref name="foo"/>
deref("foo.element") = <element> <name ns=""> "foo" </name> <group> <ref name="bar1"/> <ref name="bar2"/> </group> </element>
deref("bar1.element") = <element> <name ns="http://www.example.com/n1"> "bar1" </name> <empty/> </element>
deref("bar2.element") = <element> <name ns="http://www.example.com/n2"> "bar2" </name> <empty/> </element>

Let name class nc1 be

<name ns="http://www.example.com/n1"> "bar1" </name>

and let nc2 be

<name ns="http://www.example.com/n2"> "bar2" </name>

Then, by the inference rule (name) in Section 6.1, we have

name( "http://www.example.com/n1", "bar1" ) in nc1

and

name( "http://www.example.com/n2", "bar2" ) in nc2

By the inference rule (empty) in Section 6.2.3, we have

cx1 |- { }; ( ) =~ <empty/>

and

cx2 |- { }; ( ) =~ <empty/>

Thus by the inference rule (element) in Section 6.2.8, we have

cx0 |- { }; e1 =~ <ref name="bar1"/>

Note that we have chosen cx0, since any context is allowed.

Likewise, we have

cx0 |- { }; e2 =~ <ref name="bar2"/>

By the inference rule (group) in Section 6.2.1, we have

cx0 |- { }; e1, e2 =~ <group> <ref name="bar1"/> <ref name="bar2"/> </group>

By the the inference rule (element) in Section 6.2.8, we have

cx3 |- { }; element( name( "", "foo" ), cx0, { }, m ) =~ <ref name="foo"/>

Here cx3 is an arbitrary context.

Thus we can apply the inference rule (valid) in Section 6.3 and obtain

valid(e0)

7. Restrictions

The following constraints are all checked after the grammar has been transformed to the simple form described in Section 5. The purpose of these restrictions is to catch user errors and to facilitate implementation.

7.1. Contextual restrictions

In this section we describe restrictions on where elements are allowed in the schema based on the names of the ancestor elements. We use the concept of a prohibited path to describe these restrictions. A path is a sequence of NCNames separated by / or //.

  • An element matches a path x, where x is an NCName, if and only if the local name of the element is x
  • An element matches a path x/p, where x is an NCName and p is a path, if and only if the local name of the element is x and the element has a child that matches p
  • An element matches a path x//p, where x is an NCName and p is a path, if and only if the local name of the element is x and the element has a descendant that matches p

For example, the element

<foo>
  <bar>
    <baz/>
  </bar>
</foo>

matches the paths foo, foo/bar, foo//bar, foo//baz, foo/bar/baz, foo/bar//baz and foo//bar/baz, but not foo/baz or foobar.

A correct RELAX NG schema must be such that, after transformation to the simple form, it does not contain any element that matches a prohibited path.

7.1.1. attribute pattern

The following paths are prohibited:

  • attribute//element
  • attribute//attribute

7.1.2. oneOrMore pattern

The following paths are prohibited:

  • oneOrMore//group//attribute
  • oneOrMore//interleave//attribute

7.1.3. list pattern

The following paths are prohibited:

  • list//list
  • list//element
  • list//attribute
  • list//text

7.1.4. except in data pattern

The following paths are prohibited:

  • data/except//attribute
  • data/except//element
  • data/except//text
  • data/except//list
  • data/except//group
  • data/except//interleave
  • data/except//oneOrMore

7.1.5. start element

The following paths are prohibited:

  • start//attribute
  • start//data
  • start//value
  • start//text
  • start//list
  • start//group
  • start//interleave
  • start//oneOrMore

7.1.6. except in name classes

The following paths are prohibited:

  • anyName/except//anyName
  • nsName/except//nsName
  • nsName/except//anyName

7.2. String sequences

RELAX NG does not allow a pattern such as:

<element name="foo">
  <group>
    <data type="int"/>
    <element name="bar">
      <empty/>
    </element>
  </group>
</element>

Nor does it allow a pattern such as:

<element name="foo">
  <group>
    <data type="int"/>
    <text/>
  </group>
</element>

More generally, if the pattern for the content of an element or attribute contains two string-matching patterns (i.e. data, value, list or text patterns), then either

  • both patterns must be text patterns, or
  • the patterns must be alternatives to each other, i.e. they must occur in different alternatives of some choice pattern.

This rule does not apply to patterns occurring within a list pattern.

To formalize this, we use the concept of a content-type. A pattern that is allowable as the content of an element has one of three content-types: empty, mixed and data. We use the following notation.

empty( )
returns the empty content-type
mixed( )
returns the mixed content-type
data( )
returns the data content-type
contentType
ranges over content-types
groupable(contentType1, contentType2)
asserts that the content-types contentType1 and contentType2 are groupable

The empty content-type is groupable with anything. In addition, the mixed content-type is groupable with the mixed content-type. The following rules formalize this.

(group empty 1)
groupable(empty( ), contentType)
(group empty 2)
groupable(contentType, empty( ))
(group mixed)
groupable(mixed( ), mixed( ))

Some patterns have a content-type. We use the following additional notation.

contentType(p, contentType)
asserts that pattern p has content-type contentType
max( contentType1, contentType2 )
returns the maximum of contentType1 and contentType2 where the content-types in increasing order are empty( ), mixed( ), data( )

The following rules define when a pattern has a content-type and, if so, what it is.

(value)
contentType(<value datatypeLibrary="u1" type="ln" ns="u2"> s </value>, data( ))
(data 1)
contentType(<data datatypeLibrary="u" type="ln"> params </data>, data( ))
(data 2)
contentType(p, contentType)

contentType(<data datatypeLibrary="u" type="ln"> params <except> p </except> </data>, data( ))
(list)
contentType(<list> p </list>, data( ))
(text)
contentType(<text/>, mixed( ))
(ref)
contentType(<ref name="ln"/>, mixed( ))
(empty)
contentType(<empty/>, empty( ))
(attribute)
contentType(p, contentType)

contentType(<attribute> nc p </attribute>, empty( ))
(group)
contentType(p1, contentType1)����contentType(p2, contentType2)����groupable(contentType1, contentType2)

contentType(<group> p1 p2 </group>, max( contentType1, contentType2 ))
(interleave)
contentType(p1, contentType1)����contentType(p2, contentType2)����groupable(contentType1, contentType2)

contentType(<interleave> p1 p2 </interleave>, max( contentType1, contentType2 ))
(oneOrMore)
contentType(p, contentType)����groupable(contentType, contentType)

contentType(<oneOrMore> p </oneOrMore>, contentType)
(choice)
contentType(p1, contentType1)����contentType(p2, contentType2)

contentType(<choice> p1 p2 </choice>, max( contentType1, contentType2 ))

Note

The antecedent in the (data 2) rule above is in fact redundant because of the prohibited paths in Section 7.1.4.

Now we can describe the restriction. We use the following notation.

incorrectSchema(p, contentType)
asserts that the schema is incorrect

All patterns occuring as the content of an element pattern must have a content-type.

(element)
deref(ln) = <element> nc p </element>����not(contentType(p, contentType))

incorrectSchema()

7.3. Duplicate attributes

Duplicate attributes are not allowed. More precisely, for a pattern <group> p1 p2 </group> or <interleave> p1 p2 </interleave>, there must not be any attribute name that matches both an attribute pattern occuring in p1 and an attribute pattern occuring in p2.

8. Conformance

A conforming RELAX NG validator must be able to determine for any XML document whether it is a correct RELAX NG schema. A conforming RELAX NG validator must be able to determine for any XML document and for any correct RELAX NG schema whether the document is valid with respect to the schema.

However, the requirements in the preceding paragraph do not apply if the schema uses a datatype library that the validator does not support. A conforming RELAX NG validator is only required to support the builtin datatype library described in Section 6.2.10. A validator that claims conformance to RELAX NG should document which datatype libraries it supports. The requirements in the preceding paragraph also do not apply if the schema includes externalRef or include elements and the validator is unable to retrieve the resource identified by the URI or is unable to construct an element from the retrieved resource. A validator that claims conformance to RELAX NG should document its capabilities for handling URI references.

A. RELAX NG schema for RELAX NG

<grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
  ns="http://relaxng.org/ns/structure/0.9"
  xmlns="http://relaxng.org/ns/structure/0.9">

  <start>
    <ref name="pattern"/>
  </start>

  <define name="pattern">
    <choice>
      <element name="element">
        <choice>
          <attribute name="name">
            <data type="QName"/>
          </attribute>
          <ref name="open-name-class"/>
        </choice>
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="attribute">
        <ref name="common-atts"/>
        <choice>
          <attribute name="name">
            <data type="QName"/>
          </attribute>
          <ref name="open-name-class"/>
        </choice>
        <interleave>
          <ref name="other"/>
          <optional>
            <ref name="pattern"/>
          </optional>
        </interleave>
      </element>
      <element name="group">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="interleave">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="choice">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="optional">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="zeroOrMore">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="oneOrMore">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="list">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="mixed">
        <ref name="common-atts"/>
        <ref name="open-patterns"/>
      </element>
      <element name="ref">
        <attribute name="name">
          <data type="NCName"/>
        </attribute>
        <ref name="common-atts"/>
      </element>
      <element name="parentRef">
        <attribute name="name">
          <data type="NCName"/>
        </attribute>
        <ref name="common-atts"/>
      </element>
      <element name="empty">
        <ref name="common-atts"/>
        <ref name="other"/>
      </element>
      <element name="text">
        <ref name="common-atts"/>
        <ref name="other"/>
      </element>
      <element name="value">
        <optional>
          <attribute name="type">
            <data type="NCName"/>
          </attribute>
        </optional>
        <ref name="common-atts"/>
        <text/>
      </element>
      <element name="data">
        <attribute name="type">
          <data type="NCName"/>
        </attribute>
        <ref name="common-atts"/>
        <interleave>
          <ref name="other"/>
          <group>
            <zeroOrMore>
              <element name="param">
                <attribute name="name">
                  <data type="NCName"/>
                </attribute>
                <text/>
              </element>
            </zeroOrMore>
            <optional>
              <element name="except">
                <ref name="common-atts"/>
                <ref name="open-patterns"/>
              </element>
            </optional>
          </group>
        </interleave>
      </element>
      <element name="notAllowed">
        <ref name="common-atts"/>
        <ref name="other"/>
      </element>
      <element name="externalRef">
        <attribute name="href">
          <data type="anyURI"/>
        </attribute>
        <ref name="common-atts"/>
        <ref name="other"/>
      </element>
      <element name="grammar">
        <ref name="common-atts"/>
        <ref name="grammar-content"/>
      </element>
    </choice>
  </define>

  <define name="grammar-content">
    <interleave>
      <ref name="other"/>
      <zeroOrMore>
        <choice>
          <ref name="start-element"/>
          <ref name="define-element"/>
          <element name="div">
            <ref name="common-atts"/>
            <ref name="grammar-content"/>
          </element>
          <element name="include">
            <attribute name="href">
              <data type="anyURI"/>
            </attribute>
            <ref name="common-atts"/>
            <ref name="include-content"/>
          </element>
        </choice>
      </zeroOrMore>
    </interleave>
  </define>

  <define name="include-content">
    <interleave>
      <ref name="other"/>
      <zeroOrMore>
        <choice>
          <ref name="start-element"/>
          <ref name="define-element"/>
          <element name="div">
            <ref name="common-atts"/>
            <ref name="include-content"/>
          </element>
        </choice>
      </zeroOrMore>
    </interleave>
  </define>

  <define name="start-element">
    <element name="start">
      <ref name="combine-att"/>
      <ref name="common-atts"/>
      <ref name="open-pattern"/>
    </element>
  </define>

  <define name="define-element">
    <element name="define">
      <attribute name="name">
        <data type="NCName"/>
      </attribute>
      <ref name="combine-att"/>
      <ref name="common-atts"/>
      <ref name="open-patterns"/>
    </element>
  </define>

  <define name="combine-att">
    <optional>
      <attribute name="combine">
        <choice>
          <value>choice</value>
          <value>interleave</value>
        </choice>
      </attribute>
    </optional>
  </define>

  <define name="open-patterns">
    <interleave>
      <ref name="other"/>
      <oneOrMore>
        <ref name="pattern"/>
      </oneOrMore>
    </interleave>
  </define>

  <define name="open-pattern">
    <interleave>
      <ref name="other"/>
      <ref name="pattern"/>
    </interleave>
  </define>

  <define name="name-class">
    <choice>
      <element name="name">
        <ref name="common-atts"/>
        <data type="QName"/>
      </element>
      <element name="anyName">
        <ref name="common-atts"/>
        <ref name="except-name-class"/>
      </element>
      <element name="nsName">
        <ref name="common-atts"/>
        <ref name="except-name-class"/>
      </element>
      <element name="choice">
        <ref name="common-atts"/>
        <ref name="open-name-classes"/>
      </element>
    </choice>
  </define>

  <define name="except-name-class">
    <interleave>
      <ref name="other"/>
      <optional>
        <element name="except">
          <ref name="open-name-classes"/>
        </element>
      </optional>
    </interleave>
  </define>

  <define name="open-name-classes">
    <interleave>
      <ref name="other"/>
      <oneOrMore>
        <ref name="name-class"/>
      </oneOrMore>
    </interleave>
  </define>

  <define name="open-name-class">
    <interleave>
      <ref name="other"/>
      <ref name="name-class"/>
    </interleave>
  </define>

  <define name="common-atts">
    <optional>
      <attribute name="ns">
        <data type="anyURI"/>
      </attribute>
    </optional>
    <optional>
      <attribute name="datatypeLibrary">
        <data type="anyURI"/>
      </attribute>
    </optional>
    <zeroOrMore>
      <attribute>
        <anyName>
          <except>
            <nsName/>
            <nsName ns=""/>
          </except>
        </anyName>
      </attribute>
    </zeroOrMore>
  </define>

  <define name="other">
    <zeroOrMore>
      <element>
        <anyName>
          <except>
            <nsName/>
          </except>
        </anyName>
        <zeroOrMore>
          <choice>
            <attribute>
              <anyName/>
            </attribute>
            <text/>
            <ref name="any"/>
          </choice>
        </zeroOrMore>
      </element>
    </zeroOrMore>
  </define>

  <define name="any">
    <element>
      <anyName/>
      <zeroOrMore>
        <choice>
          <attribute>
            <anyName/>
          </attribute>
          <text/>
          <ref name="any"/>
        </choice>
      </zeroOrMore>
    </element>
  </define>

</grammar>

B. Issues

The RELAX NG TC particularly solicits feedback on the following issues.

B.1. Interleave

The TC believes it is desirable to have a constraint on the use of the interleave pattern in order to facilitate implementation, but does not yet have consensus on exactly what this constraint should be. Feedback from implementors is solicited.

B.2. References to named patterns in external grammars

Suppose a grammar A.rng wishes to use two patterns, foo and bar, defined in B.rng; A.rng cannot simply include B.rng because definitions in A.rng may conflict with definitions in B.rng. At the moment, A.rng can do the following:

<grammar>
...
<define name="B.foo">
  <grammar>
    <include href="B.rng">
      <start>
        <ref name="foo"/>
      </start>
    </include>
  </grammar>
</define>

<define name="B.bar">
  <grammar>
    <include href="B.rng">
      <start>
        <ref name="bar"/>
      </start>
    </include>
  </grammar>
</define>
...
</grammar>

Note

This assumes B.rng has a start element. If it does not, then A.rng would make each start element in the nested grammar be a sibling of the include element rather than a child.

This is arguably rather verbose and requires an implementation to work quite hard in order to avoid reading B.rng multiple times. It would be possible to introduce a feature into RELAX NG to support this situation. One possibility is to introduce a withGrammar element, which would be used as follows:

<grammar>
...
<define name="B.foo">
  <withGrammar href="B.rng">
    <ref name="foo"/>
  </withGrammar>
</define>

<define name="B.bar">
  <withGrammar href="B.rng">
    <ref name="bar"/>
  </withGrammar>
</define>
...
</grammar>

Another possibility is to allow grammar elements to have grammar elements as children, and then introduce a parentDefine element, which would be used as follows:

<grammar>
...
<grammar>
  <include href="B.rng"/>

  <parentDefine name="B.foo">
    <ref name="foo"/>
  </parentDefine>

  <parentDefine name="B.bar">
    <ref name="bar"/>
  </parentDefine>
</grammar>
...
</grammar>

Feedback is solicited on what, if anything, the TC should do about this.

C. RELAX NG TC (Non-Normative)

This specification was prepared and approved for publication by the RELAX NG TC. The current members of the TC are:

  • Fabio Arciniegas
  • James Clark
  • Mike Fitzgerald
  • KAWAGUCHI Kohsuke
  • Josh Lubell
  • MURATA Makoto
  • Norman Walsh
  • David Webber

References

Normative

Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, Eve Maler, editors. Extensible Markup Language (XML) 1.0 Second Edition. W3C (World Wide Web Consortium), 2000.

Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. W3C (World Wide Web Consortium), 1999.

John Cowan, Richard Tobin, editors. XML Information Set. W3C (World Wide Web Consortium), 2001.

T. Berners-Lee, R. Fielding, L. Masinter. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. IETF (Internet Engineering Task Force). 1998.

R. Hinden, B. Carpenter, L. Masinter. RFC 2732: Format for Literal IPv6 Addresses in URL's. IETF (Internet Engineering Task Force), 1999.

M. Murata, S. St.Laurent, D. Kohn. RFC 3023: XML Media Types. IETF (Internet Engineering Task Force), 2001.

Non-Normative

Paul V. Biron, Ashok Malhotra, editors. XML Schema Part 2: Datatypes. W3C (World Wide Web Consortium), 2001.

James Clark. TREX - Tree Regular Expressions for XML. Thai Open Source Software Center, 2001.

MURATA Makoto. RELAX (Regular Language description for XML). INSTAC (Information Technology Research and Standardization Center), 2001.

Allen Brown, Matthew Fuchs, Jonathan Robie, Philip Wadler, editors. XML Schema: Formal Description. W3C (World Wide Web Consortium), 2001.