Lists Home |
Date Index |
- From: firstname.lastname@example.org (Ron Bourret)
- To: email@example.com
- Date: Wed, 23 Sep 1998 01:04:32 +0200
And also the long rumored Section 5: Using XSchema Documents. This describes
the processing instruction used to associate XSchema documents with XML instance
documents. It also describes an experimental method for inlining XSchema
elements, suggested by Don Park.
An HTML version will be available in a day or two. Please send comments to the
list or directly to me (firstname.lastname@example.org).
-- Ron Bourret
5 Using XSchema Documents
This section describes how to associate XSchema documents with XML documents and
suggests ways to use XSchema documents.
5.1 Associating XSchema Documents with XML 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.
5.1.1 XSchema Processing Instruction
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
 XSchemaPI ::= '<?xschema' S XSchemaID S? '?>'
 XSchemaID ::= 'xschema' Eq SystemLiteral
where S, Eq, and SystemLiteral are the same as in [XML].
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
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.2.5, "Reusing
Element Declarations with Entities or Processing Instructions."
5.1.2 Inline XSchema Elements (Non-Normative)
NOTE: Inline XSchema elements are considered experimental and may change in the
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:
...log information that conforms to schema #1...
...log information that conforms to schema #2...
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
* The schema information in an XSchema element applies to all following elements
at the same level until the next XSchema element at that level is encountered.
* The schema information in an XSchema element completely replaces the schema
information in the previous XSchema element at the same level. That is, no
partial replacement of schema information is allowed.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)