[This local archive copy is from the official and canonical URL, http://www.simonstl.com/xschema/spec/xscspecv5.htm; please refer to the canonical source document if possible.]
Final Draft (1 Nov, 1998)
Please send public comments to the XML-Dev mailing list [XML-DEV] (you must join the list to post); send private comments to Simon St.Laurent or Ronald Bourret. Historical information regarding the development of XSchema is available at http://purl.oclc.org/NET/xschema.
1 Introduction
1.1 Status
1.2 Origin and Goals
1.3 Relation to Standards
1.4 Related Work
1.5 Terminology
1.6 Authors
2 XSchema Syntax
2.1 The XSchema Element
2.2 Element Declarations
2.3 Content Model Declarations
2.3.1 Empty Content Model
2.3.2 Any Content Model
2.3.3 PCData Content Model
2.3.4 Reference Content Model
2.3.5 Mixed Content Model
2.3.6 Choice Content Model
2.3.7 Sequence Content Model
2.4 Attribute Declarations
2.4.1 Attribute Types
2.4.2 Attribute Defaults
2.4.3 Combinations of Types, Defaults, and Default Values
2.5 Notation Declarations
2.6 Unparsed Entity Declarations
2.7 XSchema Extensions
2.7.1 Documentation Extensions
2.7.2 Other Extensions
2.8 id Attributes
3 XSchema and Namespaces
3.1 The XSchema Namespace
3.2 Namespaces of Elements and Attributes Being Defined
4 XSchema Documents and DTDs
4.1 DTDs in XSchema Documents
4.2 DTDs in Documents Described by XSchema Documents
4.3 Converting Between XSchema Documents and DTDs
4.3.1 Converting DTDs to XSchema Documents
4.3.2 Converting XSchema Documents to DTDs
5 Using XSchema Documents
5.1 Associating XSchema Documents with XML Documents
5.1.1 XSchema Processing Instruction
5.1.2 Inline XSchema Elements (Non-Normative)
5.2 Validation
5.3 Suggested Uses of XSchema Documents (Non-Normative)
5.3.1 Parsed Entities in XSchema Documents
5.3.2 Entity Support in XSchema
5.3.3 DTD Replacement
5.3.4 Schema Repository
5.3.5 Reusing Element Declarations with Entities or Processing Instructions
5.3.6 Reusing Schema Definitions through XLinks
5.3.7 Authoring
5.3.8 General Schema Information
5.3.9 Custom Uses
A: References
B: XSchema DTD
C: XSchema in XSchema
D: Contributors
In order for document processing to be reliable, it is necessary to be able to describe classes of documents and to verify individual documents' membership in these classes -- in other words, to be able to express constraints on documents and thus define 'document types'. XML inherits a mechanism for doing this from SGML: the Document Type Definition. XML DTDs can perform a subset of the functions of SGML DTDs.
DTDs have limited expressiveness and it is necessary to experiment with new ideas in schema design. These ideas include a syntax that is more like that of XML document content, certain kinds of extensibility and a cleaner separation between parsing and verifying. XSchema is an experimental schema language designed to provide a starting point for these experiments.
So that XSchemas will be immediately useful with existing software, the XSchema specification will describe a conversion from XSchema documents to DTDs. This initial version of the XSchema specification is deliberately simple, providing an initial base for implementations while introducing as few complicating factors as possible. Authors accustomed to DTD creation will find their tool set constricted; it is hoped that supporting software and tools available from other standards will make up for this reduced tool set.
The XSchema specification is the product of discussions on the xml-dev mailing list [XML-DEV]. This document has no official status. The editors have no affiliation with the World Wide Web Consortium (W3C), the organization developing and maintaining the XML standard, nor any affiliation with any W3C member organizations. While it is hoped that this document may eventually be submitted to the W3C as a Note, it is not an official specification and should be considered experimental.
Proposals for describing SGML document type definitions using document syntax rather than the separate declaration syntax have been under development for a number of years, and used by several tools for documentation. The current proposal arose from a number of concerns surrounding XML's usability and consistency. Originally conceived of as a mapping of DTD syntax to document syntax, the project has developed into an effort focused on creating schemas describing element and attribute structures rather than preserving every function provided by XML 1.0 DTDs.
The list of goals developed by the xml-dev discussion follows:
XSchemas use XML 1.0 document instance syntax and may be applied to XML 1.0 [XML] documents. This specification refers to several IETF standards, notably Multipurpose Internet Mail Extensions (MIME) ([RFC 2046]and [RFC 2048]) and XML Media Types [RFC 2376].
Namespace usage in XSchema is based on the 2 August, 1998 "Namespaces in XML" Working Draft [Namespaces]. Because this draft is still subject to change, all namespace attributes (the xmlns and xmlns:XSC attributes of the XSchema element and all ns, prefix, and ElementNS attributes) and processing (Section 3, "XSchema and Namespaces") are subject to change, even after the rest of the XSchema specification is finalized.
It is hoped that future versions of XSchema will use [XLink] and [XPointer] to implement schema reuse.
XSchema has been influenced by the XML-Data proposal [XML-Data]. It is hoped that XSchema may be mapped to an RDF vocabulary.
Several other proposals for XML schema languages also exist. These are Document Content Description for XML ([DCD]), Schema for Object-Oriented XML ([SOX]), and XML-Data [XML-Data]. Resource Description Framework (RDF) Schema Specification (RDF Schemas) proposes a related language, although this is not currently suitable for replacing DTDs.
The requirement levels used throughout this document reflect the approach of [RFC 2119], though keywords (like may and must) are not capitalized. Other terms used are defined in the XML 1.0 Recommendation [XML].
The XSchema specification is the result of contributions from a large number of people on the XML-Dev list, coordinated by the following, smaller group of authors. For a list of contributors, see Appendix D, "Contributors".
This section describes XSchema document syntax. In version 1.0, the XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. In future versions of XSchema, XSchema elements may be embedded in instance documents.
The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is:
<!ELEMENT XSchema (Doc?, More?, (ElementDecl | Model | AttDef | AttGroup | Notation | UnparsedEntity | Enumeration | XSchema)*)>
<!ATTLIST XSchema
xmlns CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
xmlns:XSC CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
ns CDATA #IMPLIED
ElementNS CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
Version CDATA #FIXED "1.0"
MimeType CDATA "application/xml"
FileExtension CDATA "xml"
id ID #IMPLIED>
The XSchema element contains other elements describing the XSchema and building a schema. These elements are described in later sections of this specification. The XSchema element may also contain other XSchema elements nested inside of it. This nesting of XSchema elements improves reusability of XSchemas by allowing the combination of multiple XSchemas inside of a single XSchema framework. It also allows finer-grained control over documentation for subsections of an XSchema.
The XSchema element's attributes include information about the namespaces used by XSchema and elements defined with XSchema, the version of the XSchema specification used, and information about the type of documents described by the XSchema.
The xmlns and xmlns:XSC attributes identify the URI of the namespace containing the XSchema elements. For more information, see Section 3.1, "The XSchema Namespace."
The ns attribute provides the URI of the namespace containing elements and attributes being declared, as with an ElementDecl element. The ElementNS attribute identifies the URI of the namespace of elements being referenced, as with a Ref element. The prefix attribute identifies the prefix to be used when converting the XSchema document to a DTD. These attributes can be overridden in the elements that declare and reference elements and attributes. For more information, see Section 3.2, "Namespaces of Elements and Attributes Being Defined."
Information about the XSchema specification version used to create this XSchema, contained in the Version attribute, is critical to proper handling of documents should the specification be updated in the future. This specification is identified as version 1.0. Future major and minor versions of the XSchema specification should identify themselves differently. No provision is made at this time for nesting XSchemas using different versions of the specification under a parent XSchema element.
The MimeType and FileExtension attributes are used to provide a suggested MIME (Multipurpose Internet Mail Extensions) Content-type and file extension for documents created using a particular XSchema. Applications may use this information to identify XML document types. A document library that generates XML documents dynamically could assign file extensions and MIME types based on the XSchema used.
Applications using this information should use the values stored in the first XSchema encountered during processing. For instance, if an XSchema includes another nested XSchema, the values for the MimeType and FileExtension attributes of the root XSchema should be used.
By default, most XML documents are assumed to have a MIME type of application/xml, as described in [RFC 2376]. Developers who need different MIME types for documents created using particular XSchemas may register other MIME types with the IETF, as described in [RFC 2048], or use the 'x-' prefix syntax for subtypes, as described in [RFC 2046].
For information about the id attribute, see Section 2.8, "id Attributes".
Element declarations in XSchemas are made using the ElementDecl element and its contents:
<!ELEMENT ElementDecl (Doc?, More?, Model, AttGroup?)>
<!-- Name is the element name -->
<!ATTLIST ElementDecl
Name NMTOKEN #REQUIRED
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
id ID #IMPLIED
Root (Recommended | Possible | Unlikely) "Possible">
The Name attribute identifies the name of the element, and is required. An element declaration would look like:
<ElementDecl Name="Species">
...additionalElementInformation...
</ElementDecl>
This declaration would declare an element named "Species", which would appear in an instance as:
<Species>...content...</Species>
The Name attribute must be unique within the set of elements in the defined namespace. It provides the name of the element as declared here and is also used by other elements to refer to this element in their content model declarations. The Name attribute must match the NCName production in [Namespaces]. (Effectively, this requires element names to begin with a letter or underscore and not include a colon.)
The ns attribute identifies the URI of the namespace containing this element and its attributes. The prefix attribute identifies the prefix that will be applied to this element and its attributes during conversion to DTDs. These attributes override the values of the same attributes on the XSchema element and can be overridden in the AttGroup and AttDef elements. For more information, see Section 3.2, "Namespaces of Elements and Attributes Being Defined."
The Root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Composition tools could use this to build a menu of likely starting points for a document. The Root attribute is purely a suggestion and does not require any action on the part of the processor.
For information about the id attribute, see Section 2.8, "id Attributes".
Note that an element must declare a content model of some type, using the Model element, even if that content model is empty. Documentation (in the Doc element), non-XSchema extensions (in the More element) and attribute declarations (using the AttGroup element) are optional.
Documentation about the element, additional extensions, content-model information, and attribute information are stored as sub-elements of the ElementDecl element. Documentation is covered in Section 2.7.1, Documentation Extensions. Additional extensions are covered in Section 2.7.2, Other Extensions. Content Models are covered in Section 2.3, Content Model Declarations, and attributes are covered in Section 2.4, Attribute Declarations.
Content model declarations are made within the Model sub-element of the declaration for the element to which they apply.
Model elements may appear inside XSchema elements for reusability, documentation, and reference, but will need to be linked to particular element declarations through mechanisms not yet defined (most likely XLink). All content model declarations have an optional id attribute; for more infomation, see Section 2.8, "id Attributes".
The Model element holds the content model for an element.
<!ELEMENT Model (Doc?, More?, (Ref | Choice | Seq | Empty | Any | PCData | Mixed))>
<!ATTLIST Model
id ID #IMPLIED>
Model elements are pure containers. A Model element nested inside a Choice or Seq element can only contain Doc, More, Ref, Choice, and Seq elements.
The simplest content model is empty, which indicates that the parent element has no sub-elements and no character data content. The Empty element indicates that an element is empty.
<!ELEMENT Empty EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
For example, to declare the Species element shown in the previous section empty, use the following XSchema declaration:
<ElementDecl Name="Species">
<Model>
<Empty/>
</Model>
</ElementDecl>
This would not allow the Species element to contain any text or sub-elements.
The Any content model, which allows the element to contain parsed character data or any other elements as content, is equally simple:
<!ELEMENT Any EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
Using the Any content model is much like using the Empty content model. To declare that the Species element had a content model of any, use the following declaration:
<ElementDecl Name="Species">
<Model>
<Any/>
</Model>
</ElementDecl>
This allows the Species element to contain text and any sub-elements an author desired.
The PCData content model, which allows the element to contain only parsed character data, is also represented by a single empty element.
<!ELEMENT PCData EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
Using the PCData content model is much like using the Empty and Any content models. For example, to assign the Species element a content model of PCData, use the following declaration:
<ElementDecl Name="Species">
<Model>
<PCData/>
</Model>
</ElementDecl>
This allows the Species element to contain text, but no sub-elements.
The Reference content model allows an element to specify other elements that it may contain. Ref elements identify the contained elements, as well as the frequency with which they appear:
<!ELEMENT Ref EMPTY>
<!-- Element references the name in an ElementDecl element -->
<!ATTLIST Ref
Element NMTOKEN #REQUIRED
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
A Model element may directly contain at most one Ref element. To define content models that permit or require the use of more elements, use the Any, Mixed, Choice, or Sequence content models.
The Element and ElementNS attributes identify the contained element. These must match the values of the Name and ns attributes, respectively, of an ElementDecl element elsewhere in the XSchema document. The ElementNS attribute overrides the value of the same attribute on the XSchema, Mixed, Choice, or Seq element. For more information, see Section 3.2, "Namespaces of Elements and Attributes Being Defined."
The Frequency attribute controls the number of referenced elements that may occur.
To declare that the Species element may contain a single CommonName element, and nothing else, use the following declaration:
<ElementDecl Name="Species">
<Model>
<Ref Element="CommonName" Frequency="Required"/>
</Model>
</ElementDecl>
This requires the Species element to contain a single CommonName element. To make the CommonName element optional - though it may still only appear once, set the Frequency attribute to 'Optional':
<ElementDecl Name="Species">
<Model>
<Ref Element="CommonName" Frequency="Optional"/>
</Model>
</ElementDecl>
Optional is the equivalent of the ? occurrence indicator in XML 1.0 DTDs.
To require the Species element to contain at least one but possibly multiple CommonName elements, set the Frequency attribute to 'OneOrMore':
<ElementDecl Name="Species">
<Model>
<Ref Element="CommonName" Frequency="OneOrMore"/>
</Model>
</ElementDecl>
OneOrMore is the equivalent of the + occurrence indicator in XML 1.0 DTDs.
Finally, to allow the Species element to contain any number (including zero) of CommonName elements, set the Frequency attribute to 'ZeroOrMore':
<ElementDecl Name="Species">
<Model>
<Ref Element="CommonName" Frequency="ZeroOrMore"/>
</Model>
</ElementDecl>
ZeroOrMore is the equivalent of the * occurrence indicator in XML 1.0 DTDs.
The mixed content model allows the unordered use of different element types and parsed character data. Content within an element declared as mixed can be parsed character data, one or more of the elements referenced by Ref elements nested in the Mixed element, or a mixture of both. The Mixed element in an XSchema document can contain only Ref elements; there is no need to include a PCData element because this is inherent in the mixed content model.
<!ELEMENT Mixed (Ref+)>
<!ATTLIST Mixed
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (ZeroOrMore) #FIXED "ZeroOrMore">
To declare that the Species element may contain a mix of parsed character data, CommonName elements, LatinName elements, and PreferredFood elements in any order, use the following declaration:
<ElementDecl Name="Species">
<Model>
<Mixed>
<Ref Element="CommonName"/>
<Ref Element="LatinName"/>
<Ref Element="PreferredFood"/>
</Mixed>
</Model>
</ElementDecl>
The XSchema processor should ignore any frequency attributes in Ref elements that appear as subelements of the Mixed element.
For information about the ElementNS attribute, see Section 2.3.4, "Reference Content Model."
The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. The Choice element may indicate a frequency, allowing the content model defined by the Choice model to appear one, one or zero, one or more, or zero or more times.
<!-- A Choice must have two or more children -->
<!ELEMENT Choice ((Seq | Ref | Model), (Seq | Ref | Model)+)>
<!ATTLIST Choice>
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
The simplest Choice element will contain two Ref elements and a frequency attribute. By default, the Choice element's content model is required to appear once.
To declare that a Species element may contain either a common name or a Latin name, but not both, use the following declaration:
<ElementDecl Name="Species">
<Model>
<Choice Frequency="Required">
<Ref Element="CommonName"/>
<Ref Element="LatinName"/>
</Choice>
</Model>
</ElementDecl>
The Ref elements in an Choice element may also specify the frequency with which they appear, as may the Seq elements described in Section 2.3.7, "Sequence Content Model". The Choice element is the equivalent of the choice group (element | element) in XML 1.0 DTDs. The ordering of the sub-elements within an Choice element has no effect.
For information about the ElementNS attribute, see Section 2.3.4, "Reference Content Model."
The Sequence content model allows for the sequential appearance of sub-elements. Elements, if they are required to appear, must appear in the order of the Choice and Ref sub-elements in the Seq element. The Seq element may also indicate a frequency, allowing the content model defined by the Seq model to appear one, one or zero, one or more, or zero or more times.
<!-- A Seq must have two or more children -->
<!ELEMENT Seq ((Choice | Ref | Model),(Choice | Ref | Model)+)>
<!ATTLIST Seq
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
The simplest Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. By default, the Seq element's content model is required to appear once.
To declare that the Species element requires a common name and a Latin name, in that order, use the following declaration:
<ElementDecl Name="Species">
<Model>
<Seq Frequency="Required">
<Ref Element="CommonName"/>
<Ref Element="LatinName"/>
</Seq>
</Model>
</ElementDecl>
The Ref elements in an Seq element may also specify the frequency with which they appear, as may the Choice elements. The Seq element is the equivalent of the sequence group (element, element) in XML 1.0 DTDs.
For information about the ElementNS attribute, see Section 2.3.4, "Reference Content Model."
Attributes are declared with AttDef elements. The name, type, and default value (if any) of an attribute are defined with attributes of the AttDef element, as well as whether the attribute is required. Values for enumerated types are provided by subelements.
AttGroup elements provide a container for multiple AttDef elements. If an AttGroup element is directly beneath an ElementDecl element, the contained AttDef elements apply to the element being declared. If an AttGroup element or AttDef element is directly beneath an XSchema element, the defined attributes are "global", and can only be used by reference.
<!ELEMENT AttGroup (Doc?, More?, (AttDef | AttGroup)*)>
<!ATTLIST AttGroup
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
id ID #IMPLIED>
<!ELEMENT AttDef (Doc?, More?, Enumeration?)>
<!ATTLIST AttDef
Name NMTOKEN #REQUIRED
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
Type (CData |
ID |
IDRef |
IDRefs |
Entity |
Entities |
Nmtoken |
Nmtokens |
Notation |
Enumerated) "CData"
Required (Yes | No) "No"
AttValue CDATA #IMPLIED
id ID #IMPLIED>
<!ELEMENT Enumeration (Doc?, More?, EnumerationValue+)>
<!ATTLIST Enumeration
id ID #IMPLIED>
<!ELEMENT EnumerationValue (Doc?, More?)>
<!ATTLIST EnumerationValue
Value CDATA #REQUIRED>
The Name and ns attributes provide the name of the attribute and the URI of its namespace, respectively. The value of the Name attribute must match the NCName production in [Namespaces]; that is, it must begin with a letter or underscore and cannot include a colon. If an attribute uses the same namespace as the element to which it applies, its name must be unique within that element. If it uses a different namespace or does not apply to an element, its name must be unique within the Global Attribute Partition of its namespace.
If an AttDef element is nested beneath an ElementDecl element, it applies to that element. The following example declares that the Species element has a Latin attribute:
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="Latin" ...additionalInformation.../>
</AttGroup>
</ElementDecl>
If an AttDef element is not nested beneath an ElementDecl element, it is a global attribute; a mechanism for using global attributes will be defined in a later version. The following example declares date, time, and location as global attributes:
<AttDef Name="date" ...additionalInformation.../>
...
<AttGroup>
<AttDef Name="time" ...additionalInformation.../>
<AttDef Name="location" ...additionalInformation.../>
</AttGroup>
The prefix attribute identifies the prefix that will be applied to the attribute during conversion to DTDs. For more information about prefixes and namespaces, see Section 3.2, "Namespaces of Elements and Attributes Being Defined."
For information about the id attribute, see Section 2.8, "id Attributes".
By default, attributes are assumed to contain character data (CData), not be required, and have no default value. Thus, the simplest attribute declaration requires only an attribute name:
<AttDef Name="Latin"/>
XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types. All of them are declared using attribute values within the AttDef element.
The CData attribute type is one of the most common, permitting an attribute to contain character data as defined by the XML 1.0 specification. If the Species element were to contain an attribute providing the Latin name of the species, the declaration could look like the following. (The Type attribute could actually be omitted in this case, as CData is the default type.)
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="Latin" Type="CData"/>
</AttGroup>
</ElementDecl>
This attribute would then be available for use in instances of the Species element:
<Species Latin="Passerina cyanea">...additionalContent...</Species>
The ID attribute type is used to uniquely identify elements in a document for application processing. IDRef and IDRefs attribute types are used to refer to a single ID value in the same document or multiple ID values in the same document, separated by whitespace, respectively. These attribute declarations must be used with the same constraints as apply to ID, IDREF, and IDREFS attribute types in XML 1.0.
The Entity and Entities attribute types identify the names of unparsed entities. The use of these attribute types must be made with the same constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. The name of an unparsed entity identified by an Entity or Entities attribute must match the Name attribute of an UnparsedEntity element elsewhere in the XSchema document.
The Nmtoken and Nmtokens attribute types are used to declare attributes that must contain information conforming to the Nmtoken and Nmtokens productions in XML 1.0.
The Notation and Enumerated attribute types are more complex, requiring an Enumeration subelement, which in turn contains EnumerationValue subelements, to identify their possible content. These two declarations use similar syntax, but the allowed values of Notation declarations must match the Notations declared elsewhere in the XSchema document.
If the status attribute of the Species element were to allow the values of extinct, endangered, protected, and non-threatened, an appropriate enumerated type declaration would look like:
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="status" Type="Enumerated">
<Enumeration>
<EnumerationValue Value="extinct"/>
<EnumerationValue Value="endangered"/>
<EnumerationValue Value="protected"/>
<EnumerationValue Value="non-threatened"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
A Species element created conforming to this declaration might look like:
<Species status="extinct">...additionalContentAboutDodos...</Species>
XSchema requires attribute declarations to provide information about the default value of a given attribute. XSchema provides for the four cases supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, though they are expressed as choices between required and not required with an optional default value. There may be only one default value declaration per attribute.
Required attributes (identified in XML 1.0 by #REQUIRED) are identified by assigning the value "Yes" to the Required attribute of an AttDef element and not assigning a value to the AttValue attribute. For instance, if the Latin attribute described above was required by the Species element, the AttDef element would contain a Required attribute with a value of "Yes":
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="Latin" Required="Yes"/>
</AttGroup>
</ElementDecl>
Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an AttDef element and not assigning a value to the AttValue attribute. Implied indicates that there is no default value provided, and also that no value is required. If the Latin attribute is optional, the AttDef element would contain a "No" value for the Required attribute. (Note that this is the default status and the Required declaration does not need to be made explicitly.)
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="Latin" Required="No"/>
</AttGroup>
</ElementDecl>
Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Required attribute in combination with the AttValue attribute, which must contain the fixed value for the attribute. Attributes declared as fixed can only contain the declared value for that attribute. Fixed effectively hard codes attribute values into particular elements. If the Required attribute has a value of "Yes", and the AttValue attribute is present, the attribute value should be treated as a #FIXED value in XML 1.0.
For example, to declare a planet attribute for the Species element, a Required attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value.
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="planet" Required="Yes" AttValue="Earth"/>
</AttGroup>
</ElementDecl>
Attributes may also be provided with a default value that may be overridden by other declarations. These default values are identified through the use of the AttValue attribute. The status attribute of species elements described above would be an appropriate target for such a default value, especially if most species being described fell into a particular category:
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="status" Type="Enumerated" AttValue="non-threatened"/>
<Enumeration>
<EnumerationValue Value="extinct"/>
<EnumerationValue Value="endangered"/>
<EnumerationValue Value="protected"/>
<EnumerationValue Value="non-threatened"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
Any default (required, fixed, etc.) may be used with any attribute type, though default values must always correspond to acceptable values for the attribute type.
This notation also permits the declaration of certain attributes (IDs with defaults, for instance) that are prohibited by the standard XML 1.0 DTD syntax. Developers who use these combinations should test that their documents will behave as expected in DTD-only environments as well as XSchema environments. Additional processing of document instances may be necessary to produce normalized-for-DTD use documents if they included such attributes as default values. The attribute type should always be considered more important than its default values in XSchema to DTD conversion.
The table below summarizes the possible combinations of XSchema attribute defaults and their XML 1.0 DTD equivalents.
|
Required |
AttValue |
XML 1.0 Equivalent |
|
Yes |
<value> |
#FIXED <value> |
|
Yes |
-- |
#REQUIRED |
|
No |
<value> |
AttValue |
|
No |
-- |
#IMPLIED |
(-- indicates an undeclared value)
Notation declarations are made with Notation elements nested in the XSchema element.
<!ELEMENT Notation (Doc?, More?)>
<!ATTLIST Notation
Name NMTOKEN #REQUIRED
PubidLiteral CDATA #IMPLIED
SystemLiteral CDATA #IMPLIED
id ID #IMPLIED>
The Name attribute provides the name of the notation. It must match the Name production in the XML 1.0 specification.
Notations may include a public identifier or a system literal, or both. XSchema processors should ignore Notation elements that contain neither. Public identifiers and system literals should conform to the rules in Section 4.7 of the XML 1.0 Specification.
For information about the id attribute, see Section 2.8, "id Attributes".
Unparsed entities are declared with UnparsedEntity elements nested in the XSchema element.
<!ELEMENT UnparsedEntity (Doc?, More?)>
<!ATTLIST UnparsedEntity
Name NMTOKEN #REQUIRED
SystemLiteral CDATA #REQUIRED
PubidLiteral CDATA #IMPLIED
Notation NMTOKEN #REQUIRED
id ID #IMPLIED>
The Name attribute provides the name of the unparsed entity. It must match the Name production in the XML 1.0 specification and must be unique within the set of unparsed entities defined in the XSchema document. The Notation attribute provides the name of a notation that gives the format of the unparsed entity. It must match the Name production in the XML 1.0 specification and must also match the Name attribute of a Notation element elsewhere in the XSchema document.
UnparsedEntity elements must include a system literal and may include a public identifier. Public identifiers and system literals should conform to the rules in Section 4.7 of the XML 1.0 Specification.
For information about the id attribute, see Section 2.8, "id Attributes".
XSchema provides areas in which XSchema developers can provide supplemental information and metadata regarding XSchema components in both human- and machine-readable formats. Human-readable information is provided through the use of a subset of HTML that conforms to XML syntax, while machine-readable information may be provided through the XSC:More element.
Human-readable documentation for XSchemas should be provided using the Itsy Bitsy Teeny Weeny Simple Hypertext [IBTWSH]. This is an XML DTD which describes a subset of HTML 4.0 for embedded use within other XML DTDs. It is equivalent (within its scope) to -//W3C//DTD HTML 4.0 Transitional//EN. Documentation that uses portions of the IBTWSH format may be included in the XSC:Doc element, a subelement available to all declarations. The XSC:Doc element provides basic formatting options for XSchema documentation.
<!ENTITY % ibtwsh SYSTEM "http://www.ccil.org/~cowan/XML/ibtwsh.dtd">
%ibtwsh;
<!ELEMENT XSC:Doc %struct.model;>
<!ATTLIST XSC:Doc
xmlns CDATA #FIXED "">
Note that because XSC:Doc redefines the default namespace to support IBTWSH, the XSC: prefix must be used for XSC:Doc. Any element allowed in the IBTWSH struct.model set of elements (A, ABBR, ACRONYM, ADDRESS, BIG, BLOCKQUOTE, BR, CITE, CODE, DFN, DIR, DIV, DL, EM, H1, H2, H3, HR, KBD, OL, P, PRE, SAMP, SMALL, SPAN, STRONG, UL, VAR, XML) may be used in the XSC:Doc element. To preserve compatibility with HTML, IBTWSH does not use namespaces.
XSchema applications should ignore all XSchema declarations (i.e., elements prefixed with XSC: or another appropriate XSchema prefix) within an XSC:Doc element. (The XML element of IBTWSH allows an ANY content model.)
The XSC:More element provides an area which developers can use to create their own supplements to XSchema, defining content types more tightly than is possible through XSchema 1.0. The XSC: More element has a simple ANY content model, though XSchema processors should ignore the appearance of any elements from the XSchema namespace in this area.
<!ELEMENT XSC:More ANY>
<!ATTLIST XSC:More
xmlns CDATA "">
Because XSC:More redefines the default namespace, the XSC: prefix must be used for XSC:More. Developers may override the blank value of the xmlns attribute to define their own default namespace for elements contained in the XSC:More element.
All XSchema elements except EnumerationValue, More, and Doc have an optional id attribute. These attributes, if they appear, must have a unique value within the document. They have no defined use in XSchema 1.0, but are included so that future extensions (possibly involving XLink) can uniquely identify elements in an XSchema document.
XSchema uses namespaces for its own operations and also supports schemas that take advantage of namespace facilities. XSchema processors are responsible only for elements that use the XSchema namespace appropriate to the version of XSchema they are processing. Elements in other namespaces may be used in the XSC:Doc and XSC:More elements and passed to other applications as the processor deems appropriate.
XSchema documents can be used by namespace-unaware applications provided the following conditions are met:
Note: This section is subject to change, even after the XSchema specification is otherwise finalized. For more information, see Section 1.3, "Relation to Standards."
The namespace for XSchema 1.0 is built into the XSchema DTD as the fixed default value of the xmlns and xmlns:XSC attributes of the XSchema element. The URL of the XSchema namespace is a PURL (permanent URL) provided by the OCLC. PURLs use redirection to maintain a permanent address for sites that may change address. (For more information, see http://www.purl.org.) While XSchema specification information may be stored at the location to which the PURL server redirects visitors, XSchema applications should not rely on any of that information being there.
XSC:Doc and XSC:More must use the XSC: prefix because they declare other values for the default namespace. All other XSchema elements may use the XSC: prefix if desired, but are not required to do so.
Each element or attribute defined in an XSchema document can belong to its own namespace. The URI of this namespace is provided by the ns attribute and any documents that contain the element or attribute must use the same URI. For example, if the Species element is part of the http://www.taxonomy namespace, an XSchema document might contain the following declaration:
<XSchema ns="http://www.taxonomy">
<ElementDecl Name="Species">
...additionalElementInformation...
</ElementDecl>
...
</XSchema>
The document that uses the Species element might contain:
<TAXON:Species xmlns:TAXON="http://www.taxonomy">
...additionalElementContent...
</TAXON:Species>
The ns attribute occurs on the XSchema, AttGroup, ElementDecl, and AttDef elements. Its value is inherited by lower-level elements, which can override it. In the simplest case, only the root XSchema element has an ns attribute. It is strongly recommended that the ns attribute be used only on the XSchema element.
Ref elements refer to an element defined elsewhere in the XSchema document and which may belong to a different namespace. The name and namespace of the referenced element are provided with the Element and ElementNS attributes, respectively. The ElementNS attribute occurs on the XSchema, Mixed, Choice, and Seq elements, as well as the Ref element. Its value is inherited by lower-level elements, which can override it. In the simplest case, only the root XSchema element has an ElementNS attribute.
The following example shows how the Species element, defined in the http://taxonomy namespace, is referenced in the content model of the Animal element, defined in the http://zooinventory namespace.
<XSchema>
<XSchema ns=""http://www.taxonomy">
<ElementDecl Name="Species">
...additionalElementInformation...
</ElementDecl>
...
</XSchema>
<XSchema ns=""http://www.zooinventory">
<ElementDecl Name="Animal">
<Model>
<Seq>
<Ref Element="Species" ElementNS="http://www.taxonomy" />
<Ref Element="Quantity" />
...additionalReferences...
</Seq>
</Model>
</ElementDecl>
</XSchema>
</XSchema>
If no ns or ElementNS attribute applies to an element or attribute being defined or referenced, then that element or attribute is not considered to belong to any particular namespace. In particular, the element or attribute does not belong to the XSchema namespace, nor does not belong to the current default namespace of any documents in which it is used, assuming a default namespace is defined.
For conversion to and from DTDs, XSchema provides prefix attributes, which declares the namespace prefixes used in element and attribute declarations in DTDs. This allows documents and their associated XSchemas to track the same namespace using different prefixes if necessary. XSchema-to-DTD converters should use the prefix attribute of an XSchema, ElementDecl, AttGroup, or AttDef element when creating DTD element and attribute declarations. DTD-to-XSchema converters should use the prefixes assigned in the DTD and request further information about the 'real' namespace for use in the ns attribute. This may be accomplished by parsing a sample document instance, or by direct input from the person doing the conversion.
An XSchema document is related to two different DTDs: the DTD of the XSchema document itself and the DTD of the document described by the XSchema document. This section discusses the relationship of XSchema documents to these DTDs and describes what conversions are possible between the XSchema document and the latter DTD. There is no requirement that either DTD actually exist.
An XSchema document may include a DTD as an internal subset, external subset, or both. If included, the Name in the DOCTYPE statement must be XSchema and the DTD must include all of the markup declarations in Appendix B, "XSchema DTD." It may also include additional markup declarations, such as declarations of elements to be used under the More element. However, these declarations must not override any of the declarations from Appendix B.
The main reason to include a DTD in an XSchema document is so an XSchema-unaware XML parser can supply default attribute values and determine the system and public identifiers of notations and unparsed general entities. Default attribute values are used in the XSchema DTD defined in Appendix B. Notations and unparsed general entities can be used by user-defined elements under the More element.
Secondary reasons for including a DTD in an XSchema document are to declare parsed entities (see Section 5.3.1, "Parsed Entities in XSchema Documents") and to allow the document to be validated by XSchema-unaware software.
A document described by an XSchema document may include a DTD as well as processing instructions that refer to XSchema documents (see Section 5.1.1, "XSchema Processing Instruction"). This DTD can describe the same information as the XSchema documents as well as additional information.
Reasons to include a DTD in a document described by an XSchema document include:
If an XML document includes both a DTD and processing instructions that refer to XSchema documents, it is the responsibility of the document author to ensure that the information common to both is the same. If the common information is different, it might not be possible to use the document with both XSchema-aware and -unaware software. For example, it might not be possible to validate the document against both the DTD and the XSchema documents.
If an XSchema processor is built on top of an XML parser, the XSchema processor is not required to process the DTD of the XML document. If an XSchema processor also functions as an XML parser, it is required to process the DTD only to the extent required of a non-validating parser.
Schema information can be converted between XSchema documents and DTDs, although some information may be lost. Most logical information (such as element and attribute declarations) can be converted from DTDs to XSchema documents, while some logical information (such as attribute declarations not assigned to elements) cannot be converted from XSchema documents to DTDs. In general, physical information (such as parsed entity declarations and use, the order of declarations, and the distribution of declarations among different files) either cannot be converted or is converted only at the option of the converter.
Converters may include as many or as few comments in the output document as they choose and may place these at any (legal) locations they choose. In particular, converters are not limited to converting between XSchema Doc elements and XML comments. For example, a converter might place the entire input document in one or more comments in the output document for documentation's sake or it might generate comments noting which structures it does not convert.
The following DTD structures must be converted to the corresponding XSchema structures:
The following DTD structures may be converted to the corresponding XSchema structures or discarded:
The following DTD structures cannot be converted to XSchema structures because such structures do not exist:
The following XSchema structures must be converted to the corresponding DTD structures:
The following XSchema structures may be converted to the corresponding DTD structures or discarded:
The following XSchema structures cannot be converted to DTD structures because such structures do not exist:
This section describes how to associate XSchema documents with XML documents and suggests ways to use XSchema documents.
An XSchema document can define a class of XML documents in the same way a DTD defines a class of XML documents. A document declares that it conforms to a class by including the XSchema processing instruction. A document fragment can declare that it conforms to a class by including a nested XSchema element; this latter usage is experimental.
The XSchema processing instruction is similar to the SYSTEM declaration in a DOCTYPE statement. It states that the document conforms to the class of documents described by the XSchema document. The processing instruction has the following form:
[1] XSchemaPI ::= '<?XSchema' S SystemID PubID? Version? S? '?>'
[2] SystemID ::= 'System' Eq SystemLiteral
[3] PubID ::= S 'Public' Eq PubidLiteral
[4] Version ::= S 'Version' Eq (' VersionNum ' | " VersionNum ")
where the productions S, Eq, SystemLiteral, PubidLiteral, and VersionNum are the same as in [XML]. VersionNum describes the version number of the XSchema document and must match the value of the Version attribute on the root XSchema element of the document. The rules for retrieving the XSchema document are the same as those for retrieving external entities, as described in Section 4.2.2, "External Entities," of [XML], except that an XSchema processor may choose not to retrieve the document if the version number specified by VersionNum is different from the version of XSchema supported by the processor.
An XSchema processing instruction must occur before the root element to be used; any XSchema processing instructions that occur after the root element will be ignored.
An XML document may include multiple XSchema processing instructions. The effect is as if a superior root XSchema element contains the root XSchema element of each XSchema document. This allows a document to conform to elements in many existing XSchema documents. For more information, see Section 5.3.5, "Reusing Element Declarations with Entities or Processing Instructions."
NOTE: Inline XSchema elements are considered experimental and may change in the future.
In some applications it is useful to repeatedly change the schema of the XML document at run time.
For example, consider a system that continuously logs data in XML format. From an XML standpoint, it is as if a root element was started when the system was started, all incoming information is nested beneath the root element, and the root element ends only when the system is stops. For practical purposes, the root element might not actually exist.
If the system logs information from different sources, the format (schema) of the nested elements might be different for each source. XSchema elements can be interspersed in this stream to describe the format of following information:
<Root>
<XSchema>...schema #1...</XSchema>
...log information that conforms to schema #1...
<XSchema>...schema #2...</XSchema>
...log information that conforms to schema #2...
...
</Root>
Because such use is not well-defined today, XSchema processors that use inline XSchema elements should follow these rules for the greatest chance of forward compatibility:
An XSchema processor can validate an XML document against an XSchema document; such a processor is called a validator. Because XSchema does not support parsed entity declarations (see Section 5.3.2, "Entity Support in XSchema,") this validation is slightly less comprehensive than that defined in [XML]. Validators must enforce all Validity Constraints in [XML] except:
If the instance document contains a DOCTYPE statement and the validator can discover the root element type declared there (for example, the validator parses the document itself or the parser informs it of the root element type), then the validator must enforce the Root Element Type Validity Constraint as well.
Validators, like all XSchema processors, are not required to parse XML documents.
The following sections suggest possible uses of XSchema documents. They are not binding on XSchema processors or documents.
Parsed general entities are used in XSchema documents for the same reasons they are used in XML documents: to distribute documents across multiple files, to enable multiple character encodings, to act as text substitution macros, and so on. They can also be used in a manner similar to parameter entities in a DTD. For example, suppose the DTD contains the following declaration:
<!ENTITY latinattribute "<AttDef Name='Latin' Type='CData' Required='No'/">
This can be used in the content of the XSchema document to add the Latin attribute to an element:
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
&latinattribute;
</AttGroup>
</ElementDecl>
Because parameter entities are used only in the DTD, they offer no special advantages to XSchema documents.
XSchema does not directly support parsed entities. That is, there is no XSchema element that can be used to define a parsed entity. The reason for this is that parsed entities are physical in nature. They describe how to physically construct a document: how to distribute a document across multiple files and what text substitutions to perform. This is orthogonal to the function of a schema, which is logical in nature: it describes the legal content of a document and how that content can be arranged. That a DTD can describe both the logical and physical structure of a document was viewed as a historical accident that XSchema chose not to perpetuate.
One benefit of this is that it reduces the amount of information that must be duplicated in a DTD. Because XSchema processors are expected to be built on top of XSchema-unaware parsers, any parsed entity declarations that might otherwise have been in an XSchema document would also have been required in the DTD; without them, XSchema-unaware parsers could not parse the instance documents. Such duplication of declarations is prone to error.
As was noted in Section 5.1, an XSchema document can define a class of XML documents. In this respect, it fulfills some of the functions of a DTD. That is, an XSchema processor can validate an XML document against an XSchema document and an XSchema-aware XML parser can retrieve information about the XML document, such as default attribute values and the system and public identifiers of notations and unparsed general entities.
XSchema documents are not required to define a particular class of XML documents. For example, an XSchema document might consist of nothing but attribute definitions. In this manner, an XSchema document can function as a repository for schema definitions, which can then be reused by other XSchema documents. Note that while an XSchema document that defines a class of XML documents can always act as a repository, the converse is not always true.
Element declarations in one XSchema document can be reused by referring to them in a Ref element in second XSchema document. For example, suppose an XSchema repository defines a FullName element:
<ElementDecl Name="FullName">
<Model>
<Seq>
<Ref Element="LastName"/>
<Ref Element="FirstName"/>
<Ref Element="MiddleName" Frequency="ZeroOrMore"/>
</Seq>
</Model>
</ElementDecl>
The XSchema document that describes Letter documents might include FullName by reference, where the first instance is the author of the letter and the second instance is the recipient:
<ElementDecl Name="Letter">
<Model>
<Seq>
<Ref Element="FullName"/>
<Ref Element="FullName"/>
<Ref Element="Paragraph" Frequency="OneOrMore"/>
</Seq>
</Model>
</ElementDecl>
The referenced declaration can be resolved in one of two ways. First, the second XSchema document can include the first, either by cutting and pasting or through an external parsed general entity. For example:
<!DOCTYPE XSchema [
<!ENTITY nameRepository SYSTEM "names.xsc">
]>
<XSchema>
&nameRepository;
... other declarations ...
</XSchema>
Second, a Letter (instance) document that can included processing instructions that point to both XSchema documents. For example:
<!DOCTYPE Letter>
<?XSchema SystemID="names.xsc" ?>
<?XSchema SystemID="letter.xsc" ?>
<Letter>
...
</Letter>
Note that including an XSchema processing instruction in letter.xsc that points to names.xsc will not have the intended effect. Rather than including the names.xsc, this processing instruction states that letter.xsc (an XSchema document) conforms to the elements declared names.xsc. This is unlikely to be true.
In the future, it should be possible to reuse schema definitions in an XSchema document through XLinks. Although the exact manner in which this works cannot be determined until the XLink and XPointer specifications are complete, the example from section 5.3.5 might be performed as follows:
<ElementDecl Name="Letter">
<Model>
<Seq>
<Ref Element="FullName"/>
<Ref Element="FullName"/>
<Ref Element="Paragraph" Frequency="OneOrMore"/>
</Seq>
</Model>
</ElementDecl>
<ElementDecl xml:link="simple"
href="names.xsc#id(FullName)"
inline="true"
show="replace"/>
The second ElementDecl element points to, and is replaced by, the ElementDecl element for the FullName element in names.xsc. This eliminates the need to include the names.xsc through cut-and-paste, an entity, or a processing instruction.
XSchema has been designed with such linking in mind. It is partially because of this that the container elements AttGroup, Enumeration, and Model exist and can be directly or indirectly nested inside themselves. For example, a new AttGroup might be constructed by nesting multiple AttGroup elements inside it, each of which contains an XLink to an AttGroup in a different XSchema document.
XSchema documents support authoring tools (editors) by providing human-readable documentation and a template for legal document structures.
A typical editing session using an XSchema-aware editor might proceed as follows:
An editor can also support schema building and modification. For example, it might allow the user to construct a new XSchema document from elements in existing XSchema documents or add new elements to existing XSchema documents.
Because XSchema documents can contain information about a class of documents, they can be used by tools that work with (as opposed to on) these documents. For example, a database tool might read an XSchema document and construct a database schema or a programming tool might read an XSchema document and create Java classes for each element. XSchema documents can also be used as starting points for search engines, which can use them to construct query-by-example interfaces.
The More element in XSchema provides a way for users to customize their XSchema documents. For example, subelements of the More element might be used to assign the data type (integer, date, string, etc.) of PCData elements or associate Java classes with elements.
NOTE: There are a number of existing proposals for data types in XML and it is hoped that the W3C (and therefore XSchema) will adopt one of these in the future. For example, see [DCD] or [SOX].
Tim Bray, Charles Frankston, and Ashok Malhotra. Document Content Description for XML. 31 July 1998. See http://www.w3.org/TR/NOTE-dcd.
John Cowan. Itsy Bitsy Teeny Weeny Simple Hypertext. See http://www.ccil.org/~cowan/XML/ ibtwsh.dtd.
Tim Bray, Dave Hollander, and Andrew Layman. Namespaces in XML. 2 Aug 1998. See http://www.w3.org/TR /1998/WD-xml-names-19980802.html.
Dan Brickley, R. V. Guha, and Andrew Layman. Resource Description Framework (RDF) Schema Specification. 14 August, 1998. See http://www.w3.org/TR/WD-rdf-schema.
IETF (Internet Engineering Task Force). RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, ed. N. Freed and N. Borenstein. November, 1996. See http://www.isi.edu/in-notes/rfc2046.txt.
IETF (Internet Engineering Task Force). RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, ed. N. Freed, J. Klensin, and J. Postel. November, 1996. See http://www.isi.edu/in-notes/rfc2048.txt.
IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, ed. Scott Bradner. 1997. See http://www.isi.edu/in-notes/rfc2119.txt.
IETF (Internet Engineering Task Force). RFC 2376: XML Media Types, ed. E.J.Whitehead and Murata Makoto. July, 1998. See http://www.isi.edu/in-notes/rfc2376.txt.
Matt Fuchs, Murray Maloney, and Alex Milowski. Schema for Object-oriented XML. 1998. See http://www.w3.org/TR/NOTE-SOX.
Tim Bray, Jean Paoli, and C.M. Sperberg-McQueen. Extensible Markup Language (XML) 1.0. 1998. See http://www.w3.org/TR/REC-xml.
Andrew Layman, et al. XML-Data. 5 Jan 1998. See http://www.w3.org/TR/1998/NOTE-XM L-data.
XML-DEV Mailing List, archived at http://www.lists.ic.ac.uk/hypermail/xml-dev/.
Eve Maler and Steve DeRose. XML Linking Language (XLink). 1998. See http://www.w3.org/TR/WD-xlink.
Eve Maler and Steve DeRose. XML Pointer Language (XPointer). 1998. See http://www.w3.org/TR/WD-xptr.
<!ELEMENT XSchema (Doc?, More?, (ElementDecl | Model | AttDef | AttGroup | Notation | UnparsedEntity | Enumeration | XSchema)*)>
<!ATTLIST XSchema
xmlns CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
xmlns:XSC CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
ns CDATA #IMPLIED
ElementNS CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
Version CDATA #FIXED "1.0"
MimeType CDATA "application/xml"
FileExtension CDATA "xml"
id ID #IMPLIED>
<!ELEMENT ElementDecl (Doc?, More?, Model, AttGroup?)>
<!-- Name is the element name -->
<!ATTLIST ElementDecl
Name NMTOKEN #REQUIRED
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
id ID #IMPLIED
Root (Recommended | Possible | Unlikely) "Possible">
<!ELEMENT Model (Doc?, More?, (Ref | Choice | Seq | Empty | Any | PCData | Mixed))>
<!ATTLIST Model
id ID #IMPLIED>
<!ELEMENT Empty EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
<!ELEMENT Any EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
<!ELEMENT PCData EMPTY>
<!ATTLIST Empty
id ID #IMPLIED>
<!ELEMENT Ref EMPTY>
<!-- Element references the name in an ElementDecl element -->
<!ATTLIST Ref
Element NMTOKEN #REQUIRED
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
<!ELEMENT Mixed (Ref+)>
<!ATTLIST Mixed
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (ZeroOrMore) #FIXED "ZeroOrMore">
<!-- A Choice must have two or more children -->
<!ELEMENT Choice ((Seq | Ref | Model), (Seq | Ref | Model)+)>
<!ATTLIST Choice>
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
<!-- A Seq must have two or more children -->
<!ELEMENT Seq ((Choice | Ref | Model),(Choice | Ref | Model)+)>
<!ATTLIST Seq
ElementNS CDATA #IMPLIED
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
<!ELEMENT AttGroup (Doc?, More?, (AttDef | AttGroup)*)>
<!ATTLIST AttGroup
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
id ID #IMPLIED>
<!ELEMENT AttDef (Doc?, More?, Enumeration?)>
<!ATTLIST AttDef
Name NMTOKEN #REQUIRED
ns CDATA #IMPLIED
prefix NMTOKEN #IMPLIED
Type (CData |
ID |
IDRef |
IDRefs |
Entity |
Entities |
Nmtoken |
Nmtokens |
Notation |
Enumerated) "CData"
Required (Yes | No) "No"
AttValue CDATA #IMPLIED
id ID #IMPLIED>
<!ELEMENT Enumeration (Doc?, More?, EnumerationValue+)>
<!ATTLIST Enumeration
id ID #IMPLIED>
<!ELEMENT EnumerationValue (Doc?, More?)>
<!ATTLIST EnumerationValue
Value CDATA #REQUIRED>
<!ELEMENT Notation (Doc?, More?)>
<!ATTLIST Notation
Name NMTOKEN #REQUIRED
PubidLiteral CDATA #IMPLIED
SystemLiteral CDATA #IMPLIED
id ID #IMPLIED>
<!ELEMENT UnparsedEntity (Doc?, More?)>
<!ATTLIST UnparsedEntity
Name NMTOKEN #REQUIRED
SystemLiteral CDATA #REQUIRED
PubidLiteral CDATA #IMPLIED
Notation NMTOKEN #REQUIRED
id ID #IMPLIED>
<!ENTITY % ibtwsh SYSTEM "http://www.ccil.org/~cowan/XML/ibtwsh.dtd">
%ibtwsh;
<!ELEMENT XSC:Doc %struct.model;>
<!ATTLIST XSC:Doc
xmlns CDATA #FIXED "">
<!ELEMENT XSC:More ANY>
<!ATTLIST XSC:More
xmlns CDATA "">
<?xml version="1.0"?>
<!DOCTYPE "XSchema">
<XSchema FileExtension="xsc" prefix="">
<ElementDecl Name="XSchema" Root="Recommended">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Choice Frequency="ZeroOrMore">
<Ref Element="ElementDecl"/>
<Ref Element="Model"/>
<Ref Element="AttDef"/>
<Ref Element="AttGroup"/>
<Ref Element="Notation"/>
<Ref Element="UnparsedEntity"/>
<Ref Element="Enumeration"/>
<Ref Element="XSchema"/>
</Choice>
</Seq>
</Model>
<AttGroup>
<AttDef Name="xmlns" Required="Yes" AttValue="http://www.purl.org/NET/XSchema/v1"/>
<AttDef Name="XSC" prefix="xmlns" Required="Yes" AttValue="http://www.purl.org/NET/XSchema/v1"/>
<AttDef Name="ns"/>
<AttDef Name="ElementNS"/>
<AttDef Name="prefix" Type="Nmtoken"/>
<AttDef Name="Version" Required="Yes" AttValue="1.0"/>
<AttDef Name="MimeType" AttValue="application/xml"/>
<AttDef Name="FileExtension" AttValue="xml"/>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="ElementDecl">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Ref Element="Model"/>
<Ref Element="AttGroup" Frequency="Optional"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="Name" Type="Nmtoken" Required="Yes"/>
<AttDef Name="ns"/>
<AttDef Name="prefix" Type="Nmtoken"/>
<AttDef Name="id" Type="ID"/>
<AttDef Name="Root" Type="Enumerated" AttValue="Possible">
<Enumeration>
<EnumerationValue Value="Recommended"/>
<EnumerationValue Value="Possible"/>
<EnumerationValue Value="Unlikely"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Model">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Choice>
<Ref Element="Ref"/>
<Ref Element="Choice"/>
<Ref Element="Seq"/>
<Ref Element="Empty"/>
<Ref Element="Any"/>
<Ref Element="PCData"/>
<Ref Element="Mixed"/>
</Choice>
</Seq>
</Model>
<AttGroup>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Empty">
<Model>
<Empty/>
</Model>
<AttGroup>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Any">
<Model>
<Empty/>
</Model>
<AttGroup>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="PCData">
<Model>
<Empty/>
</Model>
<AttGroup>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Ref">
<Model>
<Empty/>
</Model>
<AttGroup>
<AttDef Name="Element" Type="Nmtoken" Required="Yes"/>
<AttDef Name="ElementNS"/>
<AttDef Name="id" Type="ID"/>
<AttDef Name="Frequency" Type="Enumerated" AttValue="Required">
<Enumeration>
<EnumerationValue Value="Required"/>
<EnumerationValue Value="Optional"/>
<EnumerationValue Value="ZeroOrMore"/>
<EnumerationValue Value="OneOrMore"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Mixed">
<Model>
<Ref Element="Ref" Frequency="OneOrMore"/>
</Model>
<AttGroup>
<AttDef Name="ElementNS"/>
<AttDef Name="id" Type="ID"/>
<AttDef Name="Frequency" Type="Enumerated" Required="Yes" AttValue="ZeroOrMore">
<Enumeration>
<EnumerationValue Value="ZeroOrMore"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Choice">
<Model>
<Seq>
<Choice>
<Ref Element="Seq"/>
<Ref Element="Ref"/>
<Ref Element="Model"/>
</Choice>
<Choice Frequency="OneOrMore">
<Ref Element="Seq"/>
<Ref Element="Ref"/>
<Ref Element="Model"/>
</Choice>
</Seq>
</Model>
<AttGroup>
<AttDef Name="ElementNS"/>
<AttDef Name="id" Type="ID"/>
<AttDef Name="Frequency" Type="Enumerated" AttValue="Required">
<Enumeration>
<EnumerationValue Value="Required"/>
<EnumerationValue Value="Optional"/>
<EnumerationValue Value="ZeroOrMore"/>
<EnumerationValue Value="OneOrMore"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Seq">
<Model>
<Seq>
<Choice>
<Ref Element="Choice"/>
<Ref Element="Ref"/>
<Ref Element="Model"/>
</Choice>
<Choice Frequency="OneOrMore">
<Ref Element="Choice"/>
<Ref Element="Ref"/>
<Ref Element="Model"/>
</Choice>
</Seq>
</Model>
<AttGroup>
<AttDef Name="ElementNS"/>
<AttDef Name="id" Type="ID"/>
<AttDef Name="Frequency" Type="Enumerated" AttValue="Required">
<Enumeration>
<EnumerationValue Value="Required"/>
<EnumerationValue Value="Optional"/>
<EnumerationValue Value="ZeroOrMore"/>
<EnumerationValue Value="OneOrMore"/>
</Enumeration>
</AttDef>
</AttGroup>
</ElementDecl>
<ElementDecl Name="AttGroup">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Choice Frequency="ZeroOrMore">
<Ref Element="AttDef"/>
<Ref Element="AttGroup"/>
</Choice>
</Seq>
</Model>
<AttGroup>
<AttDef Name="ns"/>
<AttDef Name="prefix" Type="Nmtoken"/>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="AttDef">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Ref Element="Enumeration" Frequency="Optional"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="Name" Type="Nmtoken" Required="Yes"/>
<AttDef Name="ns"/>
<AttDef Name="prefix" Type="Nmtoken"/>
<AttDef Name="Type" Type="Enumerated" AttValue="CData">
<Enumeration>
<EnumerationValue Value="CData"/>
<EnumerationValue Value="ID"/>
<EnumerationValue Value="IDRef"/>
<EnumerationValue Value="IDRefs"/>
<EnumerationValue Value="Entity"/>
<EnumerationValue Value="Entities"/>
<EnumerationValue Value="Nmtoken"/>
<EnumerationValue Value="Nmtokens"/>
<EnumerationValue Value="Notation"/>
<EnumerationValue Value="Enumerated"/>
</Enumeration>
</AttDef>
<AttDef Name="Required" Type="Enumeration" AttValue="No">
<Enumeration>
<EnumerationValue Value="Yes"/>
<EnumerationValue Value="No"/>
</Enumeration>
</AttDef>
<AttDef Name="AttValue"/>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Enumeration">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
<Ref Element="EnumerationValue" Frequency="OneOrMore"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="EnumerationValue">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="Value" Required="Yes"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Notation">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="Name" Type="Nmtoken" Required="Yes"/>
<AttDef Name="PubidLiteral"/>
<AttDef Name="SystemLiteral"/>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="UnparsedEntity">
<Model>
<Seq>
<Ref Element="Doc" Frequency="Optional"/>
<Ref Element="More" Frequency="Optional"/>
</Seq>
</Model>
<AttGroup>
<AttDef Name="Name" Type="Nmtoken" Required="Yes"/>
<AttDef Name="SystemLiteral" Required="Yes"/>
<AttDef Name="PubidLiteral"/>
<AttDef Name="Notation" Type="Nmtoken" Required="Yes"/>
<AttDef Name="id" Type="ID"/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="Doc" prefix="XSC">
<Model>
<!-- The struct model from IBTWSH goes here.
Defining IBTWSH in XSchema is left as an
exercise to the reader. -->
</Model>
<AttGroup>
<AttDef Name="xmlns" Required="Yes" AttValue=""/>
</AttGroup>
</ElementDecl>
<ElementDecl Name="More" prefix="XSC">
<Model>
<Any/>
</Model>
<AttGroup>
<AttDef Name="xmlns" AttValue=""/>
</AttGroup>
</ElementDecl>
</XSchema>
|
Paul Prescod |
Peter Murray-Rust |
Alain Deseine |
|
Chris Maden |
Rick Jelliffe |
Toby Speight |
|
Jeni Tennison |
Marcus Carr |
Michael Kay |
|
James Anderson |
David Megginson |
Don Park |
|
James K. Tauber |
Tim Bray |
John Simpson |
|
Steven Champeon |
Andrew Layman |
Arjun Ray |
|
Curt Arnold |
Bill la Forge |
Bryan Gilbert |
|
Carl Hage |
Dan Brickley |
David Brownell |
|
David G. Durand |
David Ornstein |
David Rosenborg |
|
Eric Albright |
Francis Norton |
Frank Boumphrey |
|
Gisli Olafsson |
Dirk Gouders |
Guy Huard |
|
Jacek Ambroziak |
Jack Bolles |
Jarle Stabell |
|
Jeremy H. Griffith |
Jon Bosak |
Lars Marius Garshol |
|
Liam Quin |
Lisa Rein |
Mark D. Anderson |
|
Matt Mower |
Matthew Gertner |
Mark Tucker |
|
Kenneth J. Meltsner |
Murata Makoto |
Murray Maloney |
|
Parameshwor Karki |
Paul Haahr |
Paul Rabin |
|
Robin Cover |
Scott Vanderbilt |
Sean McGrath |
|
Simon North |
Stefan Wagner |
Steve Withall |
|
Steven R. Newcomb |
Thuy-Lin Nguyen |
Todd Ross |
|
W.E. Perry |
Will Hunt |
Akitoshi Yoshida |