Table of Contents
This chapter address various (pretty minor) syntax issues. If you want the whole story, see the full Relax NG schema, or nvdl.html which is a prettier version of the same information.
I stated earlier that I will only use Relax NG syntax for the schemas and sub-schemas. Taking an example of others is not a problem. Example 6.1
Example 6.1. Alternate schema usage
<?xml version="1.0" encoding="utf-8"?>
<!-- syntax.ex1.nvdl -->
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
startMode="doc">
<mode name="doc">
<namespace ns="http://document">
<validate
message="A variant on the schema specification"
schemaType="application/x-rnc">
<schema>routing.1.rnc</schema>
</validate>
</namespace>
</mode>
<mode name="rest">
<namespace ns="http://head" >
<validate schema="routing.1.xsd" />
</namespace>
<namespace ns="http://body">
<validate schemaType="application/xml-dtd"
schema="routing.1.dtd" />
</namespace>
</mode>
</rules>
Due care though. The standard says, “If v contains a schema element as a child, its content is used as the schema. When the content is a string and v has the schemaType attribute, its value shall be a MIME mediatype (see IETF RFC2046) and be used for determining the schema language. When the content is a foreign element, its namespace is used for determining the schema language.” Put simply, if it's a modern XML based schema language, then you should be OK. Otherwise specify the mimetype as per RFC2046 (ietf rfc2046).
The user has many (some might say too many) choices when validating an XML instance
Which instance parts to select
Which schema to use (or write)
Whether to use a grammar based parser or a rules based on such as Schematron
When or whether some sections can be ignored
Whether to be lax or very restrictive
All these aspects could be considered when designing the validation scenario.
How restrictive do you want to be? Remember that saying, be forgiving in what you receive and strict in what you send? How forgiving can you afford to be? It's your choice.
Some of the many options are shown here.
Use a rule to trigger an action. Rules
have various actions (reject, validate, allow, attach,
attachPlaceholder, cancelNestedActions, unwrap) which may be used
selectively to determine the validation pattern wanted. Since anyNamespace matches any section, it should be
viewed as a default action.
Rules are either within the root element or within nested mode elements.
Use modes for your initial selection. Within any mode you can
dispatch on each one of many different namespaces. Modes increase the
selective validation of any script. They can be sequenced by either
using the useMode attribute specifying
another mode, or by having a nested mode
child. The latter cannot be 'reached' from other modes (in the same
way that private methods are not accessible in an OO system). Nested
modes must be the first child of a mode in
which case they are candidates for merging if the namespaces are the
same, or a mode may be the child of a validate element and may be further nested
themselves. Example 6.2 shows this
Example 6.2. Nested modes
![]() | Note |
|---|---|
Remember that the nested |
Equally, you can call up more than one validator on any one namespace, sequencing through each one on the same section. Basic grammar checks, then business rules, then finance rules etc. You will need to understand the strength of your validators to get the best out of them
You can <reject> or <accept> an
entire namespace section. This could introduce very lax or very restrictive
processing
When selecting sections, you can use explicit namespaces, or you
could use wildcards within the namespace name, for example accepting
all namespaces from W3C. Use the wildcard character (defaults to *) in
the namespace ns attribute.
Remember that rules apply to elements
by default. Use the match attribute on
namespace ir with a value of attribute to select attributes. Note that the match attribute is also available on the anyNamespace element.
You can tailor the validator action by passing parameters to the
validator. Use the option element within the validate element