XSchema: Section 5.2

Ron Bourret (rbourret@dvs1.informatik.tu-darmstadt.de)
Wed, 23 Sep 1998 01:04:36 +0200


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

This is where we get to talk about reusing schema information and =
building Java=20
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=20
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)=0D=

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

5.2.1 Parsed Entities in XSchema Documents
=0D
Parsed general entities are used in XSchema documents for the same =
reasons they=20
are used in XML documents: to distribute documents across multiple =
files, to=20
enable multiple character encodings, to act as text substitution macros, =
and so=20
on. They can also be used in a manner similar to parameter entities in a =
DTD.=20
For example, suppose the DTD contains the following declaration:=0D

<!ENTITY latinattribute "<AttDef Name=3D'Latin' Type=3D'CData' =
Required=3D'No'/>" >=0D

This can be used in the content of the XSchema document to add the Latin =
=20
attribute to an element:=0D
=0D
<ElementDecl Name=3D"Species">=0D
...additionalElementInformation...=0D
<AttGroup>=0D
&latinattribute;=0D
</AttGroup>=0D
</ElementDecl>

Because parameter entities are used only in the DTD, they offer no =
special=20
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=20
documents. In this respect, it fulfills the logical functions of a DTD. =
That is,=20
an XSchema processor can validate an XML document against an XSchema =
document=20
and an XSchema-aware XML parser can retrieve information about the XML =
document,=20
such as default attribute values and the system and public identifiers =
of=20
notations and unparsed general entities.
=0D
5.2.3 Validation (Normative)=0D

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

Proper Declaration/PE Nesting=0D
Standalone Document Declaration=0D
Proper Group/PE Nesting=0D
Entity Declared=0D

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

An XSchema processor that validates an XML document is not required to =
parse=20
that document.
=0D
5.2.4 Schema Repository

XSchema documents are not required to define a particular class of XML=20
documents. For example, an XSchema document might consist of nothing but =
=20
attribute definitions. In this manner, an XSchema document can function =
as a=20
repository for schema definitions, which can then be reused by other =
XSchema=20
documents. Note that while an XSchema document that defines a class of =
XML=20
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=20
in a Ref element in second XSchema document. For example, suppose an =
XSchema=20
repository defines a FullName element:

<ElementDecl Name=3D"FullName">
<Model>
<Seq>
<Ref Element=3D"LastName"/>
<Ref Element=3D"FirstName"/>
<Ref Element=3D"MiddleName" Frequency=3D"ZeroOrMore"/>
</Seq>
</Model>
</ElementDecl>

The XSchema document that describes Letter documents might include =
FullName by=20
reference, where the first instance is the author of the letter and the =
second=20
instance is the recipient:

<ElementDecl Name=3D"Letter">
<Model>
<Seq>
<Ref Element=3D"FullName"/>
<Ref Element=3D"FullName"/>
<Ref Element=3D"Paragraph" Frequency=3D"OneOrMore"/>
</Seq>
</Model>
</ElementDecl>

The referenced declaration can be resolved in one of two ways. First, =
the second=20
XSchema document can include the first, either by cutting and pasting or =
through=20
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=20
that point to both XSchema documents. For example:

<!DOCTYPE Letter>
<?xschema xschema=3D"names.xsc" ?>
<?xschema xschema=3D"letter.xsc" ?>
<Letter>
...
</Letter>

Note that including an XSchema processing instruction in letter.xsc that =
points=20
to names.xsc will not have the intended effect. Rather than including =
the=20
names.xsc, this processing instruction states that letter.xsc (an =
XSchema=20
document) conforms to the elements declared names.xsc. This is unlikely =
to be=20
true.

5.2.6 Reusing Schema Definitions through XLinks

In the future, it should be possible to reuse schema definitions in an =
XSchema=20
document through XLinks. Although the exact manner in which this works =
cannot be=20
determined until the XLink and XPointer specifications are complete, the =
example=20
from section 5.2.5 might be performed as follows:

<ElementDecl Name=3D"Letter">
<Model>
<Seq>
<Ref Element=3D"FullName"/>
<Ref Element=3D"FullName"/>
<Ref Element=3D"Paragraph" Frequency=3D"OneOrMore"/>
</Seq>
</Model>
</ElementDecl>

<ElementDecl xml:link=3D"simple"
href=3D"names.xsc#id(FullName)"
inline=3D"true"
show=3D"replace"/>

The second ElementDecl element points to, and is replaced by, the =
ElementDecl=20
element for the FullName element in names.xsc. This eliminates the need =
to=20
include the names.xsc through cut-and-paste, an entity, or a processing=20
instruction.

XSchema has been designed with such linking in mind. It is partially =
because of=20
this that the container elements AttGroup, Enumeration, and Model exist =
and can=20
be directly or indirectly nested inside themselves. For example, a new =
AttGroup=20
might be constructed by nesting multiple AttGroup elements inside it, =
each of=20
which contains an XLink to an AttGroup in a different XSchema document.
=0D
5.2.7 Authoring

XSchema documents support authoring tools (editors) by providing =
human-readable=20
documentation and a template for legal document structures.

A typical editing session using an XSchema-aware editor might proceed as =
=20
follows:

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

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

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

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

An editor could also support schema building and modification. For =
example, it=20
might allow the user to construct a new XSchema document from elements =
in=20
existing XSchema documents or add new elements to existing XSchema =
documents.
=0D
5.2.8 General Schema Information=0D

Because XSchema documents can contain information about a class of =
documents,=20
they can be used by tools that work with (as opposed to on) these =
documents. For=20
example, a database tool might read an XSchema document and construct a =
database=20
schema or a programming tool might read an XSchema document and create =
Java=20
classes for each element. XSchema documents can also be used as =
starting points=20
for search engines, which can use them to construct query-by-example =
interfaces.
=0D
5.2.9 Custom Uses

The More element in XSchema provides a way for users to customize their =
XSchema=20
documents. For example, subelements of the More element might be used to =
assign=20
the data type (integer, date, string, etc.) of PCData elements or =
associate Java=20
classes with elements.

Note: There are a number of existing proposals for data types in XML and =
it is=20
hoped that the W3C (and therefore XSchema) will adopt one of these in =
the=20
future. For example, see [DCD].