[This local archive copy mirrored from the canonical site: http://users.homeaccount.com/~jbolles/XschemaSpecLong.htm; links may not have complete integrity, so use the canonical document at this URL if possible.]
Revised 18 July, 1998. Please contact Simon St.Laurent with comments. Return to XSchema home Page.
1.0 Introduction
1.1 Status
1.2 Origin and Goals
1.3 Relation to Other Standards
1.4 Terminology
2.0 XSchema Syntax
2.1 The XSchema Document
2.2 Element Declarations
2.3 Attribute Declarations
2.4 Content Model Declarations
2.5 Notation Declarations
2.6 XSchema Extensions
2.6.1 Documentation Extensions
2.6.2 Constraints on Extensions
3.0 XSchema and Namespaces
3.1 The XSchema Namespace
3.2 Interaction with Other Namespaces
3.3 Note regarding Namespace Usage
4.0 XSchema Transformation to XML 1.0 DTD
4.1 Transformation Models
4.2 Transformation Losses
5.0 Connecting XSchemas to XML Documents
5.1 Processing Models
5.2 Processing Instruction
Appendices:
A. XSchema DTD
B. XSchema declared as XSchema
Additional Notes:
1. XSchemas and XML 1.0 DTD Interactions
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).
may - XSchemas are permitted but not required to behave as described.
must - XSchemas must behave as described. Failure to behave as described constitutes an error.
error - A breach of the rules set forth in this specification. Software should report this error to the user.
element
attribute
[to be filled in as the specification develops.]
This section describes the XSchema document syntax. 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.
The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is:
<!ELEMENT XSC:XSchema (XSC:Doc?, XSC:More?, XSC:Namespace?, (XSC:ElementDecl
| XSC:AttDef | XSC:Choice | XSC:Sequence | XSC:Mixed | XSC:Ref | XSC:Notation
| XSC:XSchema)*)>
<!ATTLIST XSC:XSchema
Version CDATA #FIXED "1.0"
MimeType CDATA "application/xml"
FileExtension CDATA "xml"
id ID #IMPLIED>
The XSC:XSchema element contains other elements describing the XSchema and building a schema. These elements are described in later sections of this specification. The XSC:XSchema element may also contain other XSC:XSchema elements nested inside of it. This nesting of XSC: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 XSC:XSchema element's attributes include information about the version of the XSchema specification used as well as information about the type of documents described by the XSchema.
Information about the XSchema specification version used to create this XSchema, contained in the XSC: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 XSC:MimeType and XSC: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 XSC:MimeType and XSC: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 "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 XSC:ElementDecl element and its contents:
<!ELEMENT XSC:ElementDecl (XSC:Doc?, XSC:More?, (XSC:Ref | XSC:Choice
| XSC:Seq | XSC:Empty | XSC:Any | XSC:PCData | XSC:Mixed), XSC:AttDef*)>
<!-- Name is the element name -->
<!ATTLIST XSC:ElementDecl
Name NMTOKEN #REQUIRED
id ID #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 XSC: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 XSC: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 XSC:id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this XSC:ElementDecl element for reference using XPointers and other tools.
The XSC: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.
Note that an element must declare a content model of some type, even if that content model is empty. Documentation (in the XSC:Doc element), non-XSchema extensions (in the XSC:More element) and attribute declarations (using XSC:AttDef elements) are optional.
Documentation about the element, additional extensions, content-model information, and attribute information are stored as sub-elements of the XSC:ElementDecl element. Documentation is covered in 2.6.1, Documentation Extensions. Additional extensions are covered in 2.6.2, Further 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 the declaration for the element to which they apply.
Reference, Mixed, Choice, and Sequence models 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 simplest content model is empty, which indicates that the parent element has no sub-elements and no character data content. The XSC:Empty element indicates that an element is empty.
<!ELEMENT XSC:Empty EMPTY>
<!ATTLIST XSC:Empty
id ID #IMPLIED>
For example, to declare the Species element shown in the previous section empty, use the following XSchema declaration:
<XSC:ElementDecl name="Species">
<XSC:Empty/>
</XSC: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 XSC:Any EMPTY>
<!ATTLIST XSC: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:
<XSC:ElementDecl name="Species">
<XSC:Any/>
</XSC: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 XSC:PCData EMPTY>
<!ATTLIST XSC: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:
<XSC:ElementDecl name="Species">
<XSC:PCData/>
</XSC: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. XSC:Ref elements identify the element to be contained, as well as the frequency with which it must appear:
<!ELEMENT XSC:Ref EMPTY>
<!-- Element references the name in an ElementDecl element -->
<!ATTLIST XSC:Ref
id ID #IMPLIED
Element NMTOKEN #REQUIRED
Frequency (Required | Optional | ZeroOrMore | OneOrMore)
'Required'>
The Element attribute must refer to the Name attribute of an XSC:ElementDecl element elsewhere in the XSchema document. An XSC:ElementDecl element may contain at most one XSC: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:
<XSC:ElementDecl name="Species">
<XSC:Ref Element="CommonName" Frequency="Required"/>
</XSC: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':
<XSC:ElementDecl name="Species">
<XSC:Ref Element="CommonName" Frequency="Optional"/>
</XSC: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':
<XSC:ElementDecl name="Species">
<XSC:Ref Element="CommonName" Frequency="OneOrMore"/>
</XSC: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':
<XSC:ElementDecl name="Species">
<XSC:Ref Element="CommonName" Frequency="ZeroOrMore"/>
</XSC: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 XSC:Ref elements nested within the XSC:Mixed declaration. Only XSC:Ref elements can be nested under an XSC:Mixed element; the PCData content is inherent in the Mixed content model.
<!ELEMENT XSC:Mixed (XSC:Ref+)>
<!ATTLIST XSC: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:
<XSC:ElementDecl name="Species">
<XSC:Mixed>
<XSC:Ref Element="CommonName"/>
<XSC:Ref Element="LatinName"/>
<XSC:Ref Element="PreferredFood"/>
</XSC:Mixed>
</XSC:ElementDecl>
The XSchema processor should ignore any frequency attributes in XSC:Ref elements that appear as subelements of the XSC: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 XSC:Choice element may indicate a frequency, allowing the content model defined by the XSC: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 XSC:Choice ((Seq | Ref), (Seq | Ref)+)>
<!ATTLIST XSC:Choice
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore)
'Required'>
The simplest XSC:Choice element will contain two Ref elements and a frequency attribute. By default, the XSC: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:
<XSC:ElementDecl name="Species">
<XSC:Choice Frequency="Required">
<XSC:Ref Element="CommonName"/>
<XSC:Ref Element="LatinName"/>
</XSC:Choice>
</XSC:ElementDecl>
The XSC:Ref elements in an XSC:Choice element may also specify the frequency with which they appear, as may the XSC:Seq elements described in section 2.3.8. The XSC:Choice element is the equivalent of the choice group (element | element) in XML 1.0 DTDs. The ordering of the sub-elements within an XSC: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 XSC:Choice and XSC:Ref sub-elements in the XSC:Seq element. The XSC:Seq element may also indicate a frequency, allowing the content model defined by the XSC: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 XSC:Seq ((Choice | Ref),(Choice | Ref)+)>
<!ATTLIST XSC:Seq
id ID #IMPLIED
Frequency (Required | Optional | ZeroOrMore | OneOrMore)
'Required'>
The simplest XSC:Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. By default, the XSC: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:
<XSC:ElementDecl name="Species">
<XSC:Seq Frequency="Required">
<XSC:Ref Element="CommonName"/>
<XSC:Ref Element="LatinName"/>
</XSC:Seq>
</XSC:ElementDecl>
The XSC:Ref elements in an XSC:Seq element may also specify the frequency with which they appear, as may the XSC:Choice elements. The XSC:Seq element is the equivalent of the sequence group (element, element) in XML 1.0 DTDs.
Attribute declarations are made with empty XSC:AttDef elements. XSC:AttDef elements may be nested inside of XSC:ElementDecl element declarations or linked to element. 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.
<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?)>
<!ATTLIST XSC:AttDef
Name NMTOKEN #REQUIRED
Element NMTOKEN #IMPLIED
id ID #IMPLIED
Type (CData |
ID |
IDRef |
IDRefs |
Entity |
Entities |
Nmtoken |
Nmtokens |
Notation |
Enumerated) "CData"
Required (Yes | No) "No"
Fixed (Yes | No) "No"
Enumeration NMTOKENS #IMPLIED
AttValue CDATA #IMPLIED>
In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested within the element declaration (XSC:ElementDecl element) for the element to which the attribute belongs. If the XSC:AttDef element appears nested inside an XSC:ElementDecl element, the Element attribute must be ignored. If the XSC:AttDef element appears nested under the XSC: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 XSC:AttDef declaration applies to all elements within the declaration's parent XSC:XSchema element and any child XSC:XSchema elements.
The Name attribute of the XSC:AttDef element provides the name by which the attribute will be identified. A nested declaration is shown below.
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef Name="status" ...additionalAttributeInformation.../>
</XSC: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.
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
</XSC:ElementDecl>
...
<XSC: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.
<XSC: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.
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 XSC: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.)
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef name="Latin" Type="CData"/>
</XSC: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 an Enumeration attribute 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:
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct endangered
protected non-threatened"/>
</XSC:AttDef>
</XSC: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 and fixed or not fixed, 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 XSC:AttDef element. For instance, if the Latin attribute described above was required by the Species element, the XSC:AttDef element would contain a Required attribute with a value of "Yes":
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef name="Latin" Required="Yes"/>
</XSC:ElementDecl>
Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an XSC: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 XSC: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.)
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef name="Latin" Required="No"/>
</XSC:ElementDecl>
Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Fixed 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 Fixed attribute has a value of "Yes", the AttValue attribute must be present. A Fixed value without an AttValue must be treated as an error.
For example, to declare a planet attribute for the Species element, a Fixed attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value.
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef Name="planet" Fixed="Yes" AttValue="Earth"/>
</XSC: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:
<XSC:ElementDecl Name="Species">
...additionalElementInformation...
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct endangered
protected non-threatened" AttValue="non-threatened"/>
</XSC:AttDef>
</XSC: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 |
Fixed |
AttValue |
XML 1.0 Value |
|
Yes |
Yes |
<value> |
This does not occur in XML. It means that the instance file must include the value and the value must be the fixed value. At best this enforces duplication. |
|
Yes |
Yes |
-- |
error - Fixed=Yes without a value is clearly an error. |
|
Yes |
No |
<value> |
This does not occur in XML. It means that the instance file must include a value and the default happens to be whatever is given with AttValue. This should be treated as simply AttValue for maximum compatibility. |
|
Yes |
No |
-- |
#REQUIRED |
|
No |
Yes |
<value> |
#FIXED <value> |
|
No |
Yes |
-- |
error - Fixed=Yes without a value is clearly an error. |
|
No |
No |
<value> |
AttValue |
|
No |
No |
-- |
#IMPLIED |
Notation declarations are made with XSC:Notation elements nested in the XSC:XSchema element. .
<!ELEMENT XSC:Notation (XSC:Doc?, XSC:More?) >
<!ATTLIST XSC: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 XSC: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 %horiz.model;>
Any element allowed in the horiz.model set of elements (A, BR, SPAN, XML, CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, or parsed character data) 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 the 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>
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. (This namespace is identified with the prefix XSC: throughout this document; see 3.3 below for information about alternative prefiexes.) Information in other namespaces may be passed to other applications as the processor deems appropriate.
Please note: the information in this section is based on the 18 May 1998 "Namespaces in XML" Working Draft and is will change to maintain conformance with that specification. Some features in this section are redundant, and required at present to make certain the XSchemas will have a high likelihood of working in whatever namespace environment develops.
XSchemas created using XSchema 1.0 should include the following namespace declaration after the XML prolog but before the appearance of DTD information and the XSC:XSchema element. This namespace declaration identifies elements prefixed with XSC: as elements that should be processed by an XSchema processor and also identifies the version number of the XSchema specification used.
<?xml:namespace ns="http://www.purl.org/NET/XSchema/v1" prefix="XSC"?>
This declaration is required. XSchema processors must always check for this declaration to properly recognize the prefix that will identify XSchema elements.
XSchemas will often support document sets that have their own namespaces. Because prefixes may change from document to document, and to provide the simplest possible solution, XSchema provides a mechanism for declaring namespaces within XSchemas. This allows documents and the XSchemas used to verify them to track the same namespace using different prefixes if necessary.
<!ELEMENT XSC:Namespace (Doc?)>
<!ATTLIST XSC:Namespace
prefix CDATA #REQUIRED
ns CDATA #REQUIRED
src CDATA #IMPLIED>
The XSC:Namespace element and its contents are very similar to the <?xml:namespace?> processing instruction. The attributes of the XSC:Namespace element correspond to the prefix, ns, and src productions in the Namespaces Working Draft. The ns attribute for the namespace element is the most important part, containing a unique identifier that will be used to link the elements declared in an XSchema to their counterparts in the document. The ns attribute will contain a URI, typically a URL. (Note that #-separated identifiers are prohibited in the namespaces draft.) The src attribute can supplement the ns attribute if the unique identifier provided is not a URL but needs (perhaps) to be retrieved. The prefix attribute provides an identifier prefix that will be used throughout the XSchema to identify elements belonging to this particular namespace.
The ns attribute contains the key value that will be used to map XSchema element declarations to elements instance appearing in documents. So long as the ns attributes underlying the (possibly different) prefixes used in the XSchema and the document are the same, the mapping should work correctly. If namespaces are used which have different ns names, the mapping will be broken and the processor should report errors.
All XSC:Namespace elements within an XSchema must appear before the first XSC:ElementDecl element.
For interoperability with some interpretations of the Namespaces specification, XSchema documents must also be prefixed with namespace processing instructions that reflect the information contained in their XSC:Namespace elements. It is unclear at this point what processing model parsers will use to resolve namespaces, at what point in processing that resolution should take place, and what components of an XML document will have namespace prefixes resolved by the parser.
*** - Should namespace declarations in a parent XSC:XSchema element hold in XSC:XSchema subelements, or should they start over?
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: