21 August 1998 Draft
This specification draft contains the complete text of sections 1-3 of the XSchema specification. Section 4, XSchema Transformation to XML 1.0 DTD, and Section 5, Connecting XSchemas to XML Documents, are still under development. The sections included here are presented for review; no changes will be made to these sections until 8 September, 1998. All comments and suggestions are welcome. Please send public comments to the XML-Dev mailing list (you must join the list to post); private comments may be sent to Simon St.Laurent. Historical information regarding the development of XSchema is available at http://purl.oclc.org/NET/xschema.
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 toolset constricted; it is hoped that supporting software and tools available from other standards will make up for this reduced toolset.
The XSchema specification is the product of discussions on the xml-dev mailing list. 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 documents. XSchemas are also designed to make use of XML namespaces. It is hoped that XSchemas and RDF Schemas may be mapped to each other. This specification has also been influenced by the discussion of the XML-Data proposal made to the W3C on 5 January, 1998. XSchema also refers to several IETF standards, notably Multipurpose Internet Mail Extensions (MIME).
The requirement levels used throughout this document reflect the approach of RFC 2119 (http://www.isi.edu/in-notes/rfc2119.txt), though keywords (like may and must) are not capitalized. Other terms used are defined in the XML 1.0 Recommendation, available at http://www.w3.org/TR/1998/REC-xml-19980210.
The XSchema specification is the result of contributions from a large number of people on the XML-Dev list, coordinated by a smaller group of authors.
|
Ron Bourret |
John Cowan |
|
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 |
|
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 | XSchema)*)>
<!ATTLIST XSchema
xmlns CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
xmlns:XSC CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
prefix NMTOKEN #IMPLIED
ns CDATA #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 namespace used by XSchema, the version of the XSchema specification used, and information about the type of documents described by the XSchema.
The XSchema namespace is fixed with the xmlns attribute to correspond to the 2 August 1998 working draft of Namespaces in XML. The xmlns:XSC attribute, also fixed, allows XSchema declarations to be prefixed with XSC for situations where they need to redefine the default namespace (as is the case with XSC:Doc, and may be the case with XSC:More - see Section 2.6 for more details.) The prefix attribute identifies the prefix that will be applied to all elements and attributes defined within this XSchema element during conversion to DTDs, unless overridden in the element or attribute declaration itself. The ns attribute identifies the URI which functions as the namespace name for subelements. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces".
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, "XML Media Types," by E.J. Whitehead and Murata Makoto. Developers who need different MIME types for documents created using particular XSchemas may register other MIME types with the IETF, as described in RFC 1590, or use the 'x-' prefix syntax for subtypes, as described in RFC 1521.
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
id ID #IMPLIED
prefix NMTOKEN #IMPLIED
ns CDATA #IMPLIED
Root (Recommended | Possible | Unlikely) "Possible">
The XSC:Name attribute identifies the name of the element, and is required. An element declaration would look like:
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
</XSC: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, as 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 also match the Name production in the XML 1.0 spec. (Effectively, this requires element names to begin with a letter, underscore, or colon.)
The id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this ElementDecl element for reference using XPointers and other tools. The prefix attribute identifies the prefix that will be applied to this elements and its attributes during conversion to DTDs, unless overridden in the attribute declaration itself. The ns attribute identifies the URI which functions as the namespace name for this element and its attributes. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces".
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.
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 2.6.1, Documentation Extensions. Additional extensions are covered in 2.6.2, Other Extensions. Content Models are covered in 2.3, Content Model Declarations, and attributes are covered in 2.4, Attribute Declarations.
Content model declarations are made within 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 value for reference.
The Model element holds the content model for an element.
<!ELEMENT Model (Doc?, More?, (Ref | Choice | Seq | Empty | Any | PCData | Mixed | Model))>
<!ATTLIST Model
id ID #IMPLIED>
Model elements are pure containers, and act much like parentheses in XML 1.0 DTD declarations. If a Model element used as a part of a declaration contains content that is inappropriate to that declaration (for instance, a Mixed model in a Choice or Seq model), the processor should halt and signal a fatal error.
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 which it may contain, as well as their quantity. Ref elements identify the element to be contained, as well as the frequency with which it must appear:
<!ELEMENT Ref EMPTY>
<!-- Element references the name in an ElementDecl element -->
<!ATTLIST Ref
id ID #IMPLIED
Element NMTOKEN #REQUIRED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
The Element attribute must refer to the Name attribute of an ElementDecl element elsewhere in the XSchema document. An ElementDecl element may contain at most one Ref element.
The Frequency attribute controls the number of referenced elements that may occur. To define content models that permit or require the use of more elements, the Any, Mixed, Choice, or Sequence content models should be used as appropriate.
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.
Mixed content model allows the unordered use of different element types and character data. Content within an element that uses a mixed declaration must be PCData or one or more of the elements referenced by Ref elements nested within the Mixed declaration. Only Ref elements can be nested under an Mixed element; the PCData content is inherent in the Mixed content model.
<!ELEMENT Mixed (Ref+)>
<!ATTLIST Mixed
id ID #IMPLIED
Frequency (ZeroOrMore) #FIXED "ZeroOrMore">
To declare that the Species element may contain a mix of PCData, 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.
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
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.8. 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.
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
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.
Attribute declarations are made with AttDef elements nested inside of AttGroup container elements. AttGroup elements may be nested inside of ElementDecl element declarations or XSchema elements. The type of an attribute is defined with an attribute, as is a declaration of whether or not it is required and a possible default value. Values for enumerated types are provided with subelements.
<!ELEMENT AttGroup (Doc?, More?, AttDef*)>
<!ATTLIST AttGroup
Name NMTOKEN #IMPLIED
Element NMTOKEN #IMPLIED
id ID #IMPLIED
prefix NMTOKEN #IMPLIED
ns CDATA #IMPLIED>
<!ELEMENT AttDef (Doc?, More?, EnumerationValue*)>
<!ATTLIST AttDef
Name NMTOKEN #REQUIRED
Type (CData |
ID |
IDRef |
IDRefs |
Entity |
Entities |
Nmtoken |
Nmtokens |
Notation |
Enumerated) "CData"
Required (Yes | No) "No"
AttValue CDATA #IMPLIED>
<!ELEMENT EnumerationValue (Doc?, More?)>
<!ATTLIST EnumerationValue
Value CDATA #REQUIRED>
In XSchema 1.0, attribute declarations (AttDef elements inside of an AttGroup element) may be nested within the element declaration (ElementDecl element) for the element to which the attribute belongs, or outside of that structure in an XSchema element. If the AttGroup element appears nested inside an ElementDecl element, the Element attribute must be ignored. Similarly, if an AttDef element appears nested inside an AttGroup element, its Element attribute must be ignored in favor of that of the AttGroup. If an AttGroup or AttDef element appears nested under the XSchema element, the Element attribute may contain a name token corresponding to the Name attribute of the element to which this attribute applies. If the Element attribute is missing, that AttDef or AttGroup declaration may only be used by reference.
AttGroup elements are container elements. All of their attributes, except for id, apply to the child AttDef elements and may be overridden by the attributes of those child elements. The Name attribute of the AttGroup element is provided for convenient reference within the XSchema. This attribute should be ignored in conversions to DTDs.
The Name attribute of the AttDef element provides the name by which the attribute will be identified. Attribute names must be unique within the element in which they are declared. A nested declaration is shown below.
<ElementDecl Name="Species">
...additionalElementInformation...
<AttGroup>
<AttDef Name="status" ...additionalAttributeInformation.../>
</AttGroup>
</ElementDecl>
This declares an element with the name Species that has an attribute named status. If the status attribute was declared outside of the Species element declaration, the declarations would appear as shown below.
<ElementDecl Name="Species">
...additionalElementInformation...
</ElementDecl>
...
<AttDef Name="status" Element="Species" ...additionalAttributeInformation.../>
Merely naming an attribute may be adequate. Attribute declarations may identify types and provide information about whether the attribute is required. By default, attributes will be assumed to contain character data (CData), not be required, and have no default value. This information is declared using additional attributes. The simplest attribute declaration possible identifies an attribute as containing character data (CData) and allows the attribute to be optional, as shown below.
<AttDef Name="sampleAttribute"/>
Applications may also use the id attribute to provide unique identifiers for attribute declarations using values that are unique within the XSchema.
The prefix attribute identifies the prefix that will be applied to this attribute during conversion to DTDs. The ns attribute identifies the URI which functions as the namespace name for this attributes. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces".
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. If a document is checked directly against an XSchema without a conversion to a DTD, information regarding unparsed entities must be available from the parser for these attribute types to be meaningful.
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 Enumeration 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">
<EnumerationValue Value="extinct"/>
<EnumerationValue Value="endangered"/>
<EnumerationValue Value="protected"/>
<EnumerationValue Value="non-threatened"/>
</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. 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 using fixed value cannot declare a different 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" Enumeration="extinct endangered protected non-threatened" AttValue="non-threatened"/>
</AttGroup>
</ElementDecl>
Any default (required, fixed, etc.) may be used with any attribute type, though default values should 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 empty or undeclared value)
Notation declarations are made with Notation elements nested in the XSchema element.
<!ELEMENT Notation (Doc?, More?) >
<!ATTLIST Notation
Name NMTOKEN #REQUIRED
id ID #IMPLIED
PubidLiteral CDATA #IMPLIED
SystemLiteral CDATA #IMPLIED>
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.
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) format created by John Cowan. The full DTD is available at http://www.ccil.org/~cowan/XML/ibtwsh.dtd. 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 (CITE, CODE, DFN, EM, BIG, SMALL, KBD, SAMP, STRONG, VAR, ABBR, ACRONYM, A, BR, SPAN, XML, BLOCKQUOTE, DIV, HR, P, PRE, DL, UL, OL, DIR, H1, H2, H3, ADDRESS) may be used in the XSC:Doc element. Note that IBTWSH does not use namespaces in order to preserve compatibility with HTML.
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.
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. Information in other namespaces may be used in the XSC:Doc and XSC:More elements and passed to other applications as the processor deems appropriate.
Please note: the information in this section is based on the 2 August 1998 "Namespaces in XML" Working Draft and is will change to maintain conformance with that specification.
XSchemas created using XSchema 1.0 have their namespace declaration built into the DTD as default xmlns and xmlns:XSC attributes of the XSchema element. Note that XSC:Doc and XSC:More must use the XSC: prefix because they declare other values for the default namespace name. Any XSchema element may use the XSC: prefix if desired, but it is not necessary.
XSchemas will often support document sets that have their own namespaces. To maintain interoperability with DTDs, XSchema provides mechanisms for declaring the namespace prefixes of elements declared by XSchemas. This allows documents and the XSchemas used to verify them to track the same namespace using different prefixes if necessary. XSchema-to-DTD converters should use the prefix attribute of an ElementDecl, AttGroup, or AttDef element to create DTD element and attribute declarations containing that prefix. DTD-to-XSchema converters should use the prefixes assigned in the DTD, and request further information about the 'real' namespace for the ns attribute. This may be accomplished by parsing a sample document instance, or by direct input from the person doing the conversion.
The ns attribute is not required, but it does provide the XSchema with a level of understanding about namespaces that DTDs presently lack. If an XSchema contains the correct ns attributes, it is far better equipped to process documents that use namespaces without concern for the variability of prefixes.
Namespaces are still in development at this time, and as such are subject to dramatic change.
This specification was written making several assumptions, which may or may not prove to be true as the Namespaces draft evolves:
The only part of a namespace declaration that genuinely identifies the namespace is the ns production. The prefix only serves as a proxy for the full ns production. The URLs in a namespace declaration will not need to be retrieved. The XSchema namespace declaration uses a PURL (permanent URL) provided by the OCLC. (For details on PURLs, visit http://purl.org.) PURLs use redirection to maintain a permanent address for sites that may change address. 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.
<!ELEMENT XSchema (Doc?, More?, (ElementDecl | Model | AttDef | AttGroup | Notation | XSchema)*)>
<!ATTLIST XSchema
xmlns CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
xmlns:XSC CDATA #FIXED "http://www.purl.org/NET/XSchema/v1"
prefix NMTOKEN #IMPLIED
ns CDATA #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
id ID #IMPLIED
prefix NMTOKEN #IMPLIED
ns CDATA #IMPLIED
Root (Recommended | Possible | Unlikely) "Possible">
<!ELEMENT Model (Doc?, More?, (Ref | Choice | Seq | Empty | Any | PCData | Mixed | Model))>
<!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
id ID #IMPLIED
Element NMTOKEN #REQUIRED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
<!ELEMENT Mixed (Ref+)>
<!ATTLIST Mixed
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
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
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore) 'Required'>
<!ELEMENT AttGroup (Doc?, More?, AttDef*)>
<!ATTLIST AttGroup
Name NMTOKEN #IMPLIED
Element NMTOKEN #IMPLIED
id ID #IMPLIED
prefix NMTOKEN #IMPLIED
ns CDATA #IMPLIED>
<!ELEMENT AttDef (Doc?, More?, EnumerationValue*)>
<!ATTLIST AttDef
Name NMTOKEN #REQUIRED
Type (CData |
ID |
IDRef |
IDRefs |
Entity |
Entities |
Nmtoken |
Nmtokens |
Notation |
Enumerated) "CData"
Required (Yes | No) "No"
AttValue CDATA #IMPLIED>
<!ELEMENT EnumerationValue (Doc?, More?)>
<!ATTLIST EnumerationValue
Value CDATA #REQUIRED>
<!ELEMENT Notation (Doc?, More?) >
<!ATTLIST Notation
Name NMTOKEN #REQUIRED
id ID #IMPLIED
PubidLiteral CDATA #IMPLIED
SystemLiteral CDATA #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 "">