xml-dev - XSchema: Section 5.2

[rbourret@dvs1.informatik.tu-darmstadt.de (Ron Bourret)]

This is (except for the XSchema in XSchema appendix), the FINAL section of the 
XSchema specification.  It suggests various uses for XSchema documents and 
points at some directions we might go in the future.  Except for the section on 
validation, it is non-normative and therefore might fit better in an appendix or 
separate document.

This is where we get to talk about reusing schema information and building Java 
classes from XSchema documents and so on, so have at it.

An HTML version will be available in a day or two.  Please send comments to the 
list or directly to me (rbourret@dvs1.informatik.tu-darmstadt.de).

-- Ron Bourret


5.2 Suggested Uses of XSchema Documents (Non-Normative except as noted)

The following sections suggest possible uses of XSchema documents. Except for 
Section 5.2.3, "Validation", they are not binding on XSchema processors or 
documents.

5.2.1 Parsed Entities in XSchema 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.

5.2.2 DTD Replacement

As was noted in Section 5.1, an XSchema document can define a class of XML 
documents. In this respect, it fulfills the logical 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.

5.2.3 Validation (Normative)

An XSchema processor can validate an XML document against an XSchema document. 
Because XSchema does not support parsed entity declarations, this validation is 
slightly less comprehensive than that defined in [XML]. XSchema processors that 
perform validation must enforce all Validity Constraints in [XML] except:

Proper Declaration/PE Nesting
Standalone Document Declaration
Proper Group/PE Nesting
Entity Declared

When enforcing the Root Element Type constraint, the XSchema processor first 
checks if there is a DOCTYPE statement in the XML document. If so, it uses the 
root element type declared there. If not, it searches the XSchema document for 
element declarations in which the Root attribute has a value of Recommended. The 
root element of the XML document must be one of these elements. If no element 
declarations have a Root attribute with a value of Recommended, the validation 
fails.

An XSchema processor that validates an XML document is not required to parse 
that document.

5.2.4 Schema Repository

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.

5.2.5 Reusing Element Declarations with Entities or Processing Instructions

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 xschema="names.xsc" ?>
<?xschema xschema="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.

5.2.6 Reusing Schema Definitions through XLinks

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.2.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.

5.2.7 Authoring

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:

1) The editor displays a list of available XSchema documents. The user chooses 
an XSchema document to use as a template.

2) The editor reads the chosen document and displays a list of elements for 
which the Root attribute has a value of Recommended. The user chooses a starting 
element.

3) The editor prompts the user for element content and attributes based on the 
information in the XSchema document. When the user requests help about a  
particular structure, the editor retrieves it from the corresponding Doc  
element.

4) When the user is done, the editor saves the new document. At the start of 
this document, the editor inserts a DOCTYPE statement declaring the root element 
type and an XSchema processing instruction declaring the template XSchema 
document.

An editor could 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.

5.2.8 General Schema Information

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.

5.2.9 Custom Uses

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].

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)