An instance XML file can specify its validating schema by adding some information in
the attributes of the root tag. This is illustrated in
line 8‑
of Example 2.2
(page ), where we indicate the
location of the schema with no namespace using the
xsi:noNamespaceSchemaLocation
attribute. We then include
(using an
xi:include
element) the
WineCatalog.xml
file (Example 2.3) so that its elements can be referred to. In
fact, the XML processor sees the full content of these files (i.e. the cellar and
the wine catalog).
Example 2.1
((page )) illustrates the file inclusion
mechanism for the instance files. They correspond to their respective XML Schema in
Example 3.5.
xi:include
refers to the W3C standard
[35]
which specifies a general purpose inclusion mechanism to merge information from
different XML files. So it is possible to include only some well-formed parts of the
included file, but here we include the whole wine catalog. This is a principled way of
including information and not mere character inclusions like the one specified with DTD
system entities used in
Section 3.1.1.
Example 2.2
(page ) also shows that even if a file
is validated with an XML Schema, a DOCTYPE
element can be added to define
new entities . In fact, it is the only way to define an entity in an instance file
validated with an XML Schema.
line 1‑
of Example 2.3
(page )
shows how to link an instance file and define its namespace. The empty namespace,
defined by the
xmlns
attribute in the root tag (line 4‑), indicates that all
element tags without prefix are defined in the
http://www.iro.umontreal.ca/lapalme/wine-catalog
namespace. The schema location is indicated as the value of the
xsi:schemaLocation
(line 2‑) attribute with two values (blank
separated). The first part indicates the namespace corresponding to the target namespace
of the schema and the second part gives its URI (here the local file
WineCatalog.xsd
).
RELAX NG specifications [15] do not prescribe how an instance file should be linked to its schema, so each XML editor or validator has an implementation-specific way of associating these files (either internally or externally). For example, <oXygen/> uses processing instructions inserted at the top of the file such as the following (depending on whether the compact syntax is used or not):
<?oxygen RNGSchema="CellarBook.rnc" type="compact"?> <?oxygen RNGSchema="CellarBook.rng" type="xml"?>
The Schematron specification does not prescribe the link mechanism between an instance file
and its Schematron rule base. With the <oXygen/> XML editor, it is sufficient to add a
processing instruction like
<?oxygen SCHSchema="CellarBook.sch"?>
to a XML Schema validated file such as
Example 2.2
or to get
both
types of validation: XML Schema and Schematron. It is also possible to embed Schematron rules
within
xs:appinfo
and
xs:annotation
elements of an XML Schema which is then linked as described above. Similar embedding
conventions have be defined for both RELAX NG and RELAX NG Compact.