Native XML databases - Making Sense of NoSQL - page 113

same data types defined in the original XML Schema specification, it's easy to verify
data types and check for data types in your functions. Once you learn the data types
used on one system, you'll know how to use them in all systems.
For example, if you have a data element that must be a nonzero positive integer,
you can declare the data type of that element in your XML schema as xs:positive-
Integer . You can then use an XML schema to validate those elements and receive noti-
fication when data varies from a valid format. If a zero, negative, or non-integer is
used in that element, you can receive a notification at any stage of your data loading
process. Even if you have data issues, you can choose to load the data and perform
cleanup operations using a script later on. In a similar way, an XQuery function that
must have a positive integer as a parameter can use the same positive integer data type
and perform the same consistency checks on input or output elements.
Because XML Schema is a widely used mature standard, there are graphical tools
available to create and view these structures. A example of this view is shown in
figure 5.8 using the oXygen IDE .
This figure shows how simple graphical symbols are used to show both the struc-
ture and rules of a document. After learning the meaning of around a dozen symbols,
nontechnical users can play an active role in the design and verification of document
structures. For example, a solid black line in a schema diagram indicates that a
required element must be present for the document to be valid. A gray line implies
that an element is optional. One quick glance at a diagram can quickly indicate a spe-
cific rule. Using a black solid line for required elements isn't part of any W3C stan-
dards, but most XML developer tools use similar conventions.
XML schemas are designed to perform a single pass, looking at the structure of the
document and the data formats in each of the leaf elements. This single-pass
approach can check approximately 95% of the rules that concern business users.
There are still a few types of rules that XML schemas aren't designed to check. For
these rules, you use a companion format called Schematron.

5.4.2 Using Schematron to check document rules

Schematron is considered the “feather duster” of document validation. Schema-
tron's focus is the hard-to-reach areas of data type checking that can't be done in a
single pass with XML Schema. Let's say you want to check that the sum of all the line
items in a sales order is equal to the sales total; you could do this with a Schematron
rule. Schematron rules are used whenever you're comparing two or more places in
an XML document.
Users like Schematron document rules because they can customize the error mes-
sage associated with each rule to have a user-appropriate meaning. This customization
is more difficult with XML Schema, where an error message tells you where the error
occurred within the file but may not return a user-friendly message. For this reason,
sometimes Schematron is preferred in situations where error messages are sent to a
system user.