Featured Post

Applying Email Validation to a JavaFX TextField Using Binding

This example uses the same controller as in a previous post but adds a use case to support email validation.  A Commons Validator object is ...

Saturday, December 18, 2010

Structured Schema Designer and schemaLocation

If you're working with complex XSDs, you may need to divide your definition into several schemas or may need to use a schema that was created by someone else. If this is the case, you'll need to import the other schemas and provide cues to tooling (like Pervasive's Structured Schema Designer) on where to find the other XSD files.

This is done with the import element, a part of the standard XMLSchema definition. The import element should be used with 2 attributes: namespace and schemaLocation. The namespace will be used by the XML to link elements up with their unambiguous definition. For example, distinguishing between <myschema:total value="150" /> and <yourschema:total computedValue="150000" />. schemaLocation points to the authoritative source for the XSD.

See the following XSD snippet.

<xs:schema targetNamespace="http://www.all-travel-data.com/atd"

<xs:import namespace="http://www.all-travel-data.com/atd-common"

There is a file called atd.xsd that references atd-common.xsd. atd-common.xsd provides common type definitions and is referred to using the namespace "http://www.all-travel-data.com/atd-common". Shorthand, XML elements will refer to atd-common as "cmn" in accordance with the attribute in <xs:schema>

schemaLocation is pointing to a file on a web server (it's really there). With Structured Schema Designer, it's important that schemaLocation be set. Otherwise you'll get this error.

Sometimes in development, it's handy to use copies of files. However, this practice often causes problems with tooling because schemaLocation is a URI and not a fully-qualified file path like C:/schemas/atd-common.xsd. Structured Schema Designer can ease development because once the structured schema is generated, it can be used without referring to the XSD.

In most cases, your XML data will take definitions from multiple schemas. This is so that solutions can be composed instead of re-created new definitions with each new XML initiative. If you're using Pervasive Data Integrator, or other tools, be aware that you'll need to accurately set the schemaLocation attribute on any import statements.

This post is replicated from http://my.opera.com/walkerca/blog/schemalocation.

No comments:

Post a Comment