Validate an XML document

XMLSpear supports validation against a schema (xsd) or a document type definition (dtd). You turn on the validation by pressing the green validation button on the toolbar. If you have not choosen the type of validation(DTD or xsd) then you will be prompted to choose it. Every change that you make in the document will now immediately be checked against the schema. If the location of the schemas are not or incorrectly hinted in the xml document, you can manually give them. Please pay special attention to the method of using the file tree for assigning schemas.

Resolving the location of schemas

When the xml is validated, the parser asks for the schema which is associated with the parsed element (or attribute). If the element belongs to a namespace, then the schema that is bound to that namespace is used. Sometimes the xml documents contains hints where to look for a schema. This is done by a schemaLocation attribute. The schemaLocation attribute contains a list of pairs that associate namespaces with schemas. For example:
xsi:schemaLocation="http://example.com/product     product.xsd
	            http://example.com/order       order.xsd"
In this case you can easily validate the document by just pressing the green validation button. If the parser meets an element with the namespace http://example.com/order, then the schema order.xsd will be used to validate this element.

By the way: you can also include a noNamespaceSchemaLocation attribute to define the schema which should be used for elements (or attributes) which do not belong to a namespace.

If the parser asks for a schema that is not "hinted" in the XML or if schema can not be loaded from the hinted location, then XMLSpear will come with a popup that asks you to locate the schema.

Manually binding schemas

As mentioned above, schemas are normally resolved by looking to the schemaLocation or noNamespaceSchemaLocation attribute. But in many situations the xml is transferred from one to another place, and the schemalocation still points to a location that is not valid in the target environment.
You could solve that by:
But XMLSpear gives you also another very convenient way, without changing the actual XML or moving schemas to other places. You can add extra schema mappings that will be used in the validation.
These extra schema mappings (called pooled mappings) will overrule a mapping from the schemaLocation or noNamespaceSchemaLocation attribute. You can see the result of this action in the SchemaMappings window. An extra row with the "mapped by" set to "User (pooled)" will be present.
By the way:
Instead of using the file tree and "assign schema", you can also use the plus sign in the SchemaMappings window. However, using the file tree is much more convenient. You can organize your schemas in folders to further optimize this way of binding schemas. Most of the time you will first assign the schemas and then start the validation by pushing button. In fact this method of mapping schemas is very similar to using XML catalogs, but it is more dynamic and specific to the particular XML instance that you are validating.

Refreshing a changed schema

All schemas that are used in the validation are cached im memory. Sometimes you may want to change a schema and see the effect in the validation. However, this will have no effect because of the active caching. There are several way to force the use of the changed schema.