XSchema: Sections 5.0 and 5.1

[Ron Bourret]

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 (rbourret at dvs1.informatik.tu-darmstadt.de).

-- 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 
following form:

[1] XSchemaPI ::= '<?xschema' S XSchemaID S? '?>'
[2] 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 
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.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 
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:

* 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:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)