|
Rules for Schema Subsets |
|
|
|
Rules for Schema Subsets |
|
This document is a draft, and is under
continual revision.
The latest version may be obtained online.
Many users have found that specific XML Schema validation tools operate slowly when validating against the justice data model schemas. The justice data model schemas are, however, reference schemas, and need not be imported whole. This document lays out the rules under which users may construct schemas that are subsets of the full justice data model schemas. Such schemas may be used by applications and tools that do not to accept the entire justice data model.
The forthcoming schema subset tool will solve this problem for many users. It will allow users to develop their desired subset interactively, and will generate a full set of conformant schemas for them. An XSL-based toolset is also being developed for creating subset schemas.
Neither tool is required for generating subset schemas; they may be created with any good text editor. Subset schemas may be created through careful removal of non-required components in accordance with the rules, or they may be created additively, by adding required components. The deletion / removal method is quite tedious. The additive method, when done by hand, is prone to error caused by pasting components in the wrong order. This is why the XSL tooset is being developed.
In generating a subset schema, there is one primary, overriding rule:
Instances that validate to the subset schema will validate to the full schema.
All of the guidelines which follow keep this primary rule as the goal. We generate schemas that are subsets of the original schema. Substitution of the full schema in place of the subset is always an option. Any instance that validates to a subset schema will validate to the full justice data model schema.
This information in this document is quite technical, and requires an understanding of the justice data model, as well as XML Schema. Readers unfamiliar with either may wish to study those areas before proceeding.
Schema size may be reduced by removing any component that is not required . This is most easily done by starting with initial requirements and following the algorithm .
The initial requirements of an application are:
Requirements of valid data instances: All of the elements, attributes, type names, and other components from the justice data model that are to be considered valid in an applications XML instance data.
Requirements of non-justice data model schemas (" outside schemas "): All of the elements, attributes, type names, and other components from the justice data model that will appear in schemas not defined as part of the justice data model.
This includes the reuse of justice data model elements
in non-Global JXDM structures. For example, the inclusion of a
justice:PersonName element in a user-constructed schema.
Such an inclusion would require the justice:PersonName
global element definition
The algorithm for constructing a minimal schema subset to satisfy requirements:
A component is any of the following. Each component lists the ways in which it may be required , and other components which it may require.
A namespace prefix declaration is required when the declared prefix is used anywhere within the schema file.
For example, if an entity from the 'http://xyz.com/ns' namespace is used within the schema, then a namespace declaration must be included for that namespace.
Each schema defines the contents of a single namespace (the targetNamespace of the schema). If Schema B refers to an entity of Schema A (an entity in the namespace defined by Schema A), then Schema B must import Schema A. If Schema B does not refer to an entity of Schema A, then Schema A need not import Schema B.
An import is required when any component from the namespace which it imports is used within the schema file.
A type definition is required when:
This requirement should not be ignored. When defining a type, it is important that all base types of that type be included in the schema. Even if they are empty (i.e. have no attribues or elements), they should be included. A base type may be empty if there are no requirements for elements or attributes of that type to appear in instances or outside schemas . Even in such a case, the type should still be included, preserving the type hierarchy.
A type definition may require other components:
This type may be simple or complex. Also required are the base type of that type, and the base type of that type, etc.
Every element that represents a data model entity has a single definition in the schema. A global element definition is required when:
A global element definition requires:
Every attribute in the schema that represents a data model
property is given a single definition. Each use of the attribute references that definition (using ref=)
A global attribute definition is required when:
A global attribute defintion requires:
An occurrence of an element in a type is required when:
An instance of a type uses the element.
For example, if an instance of PersonType contains PersonName, then the element PersonName is required to occur in the type PersonType.
An instance of a subclass of the type uses the element.
For example, an instance of EnforcementOfficialType requires PersonName, then the element PersonName is required to occur in the type PersonType, since EnforcementOfficialType inherits PersonName from PersonType.
An occurrence of an element in a type definition requires:
An occurrence of an attribute in a type is required when:
It requires:
An occurrence of an attribute in the SuperTypeMetadata is required when:
An enumeration is required when:
What we've specified up to this point is the set of rules for when objects are required. Here we summarize specifically what may be omitted from the subset schema.
xmlns: attributes.xsd:import elements.xsd:complexType
and xsd:simpleType elements that are
"top-level" (direct children of the xsd:schema
element.xsd:element
elements that are children of the xsd:schema
element.xsd:attribute
elements that are children of the xsd:schema
element.xsd:element
elements that are contained in a type definition.xsd:attribute elements that are contained in a type
definition.xsd:attribute elements that appear in the
SuperTypeMetadata attributeGroup.xsd:enumeration elements, within a
simple type, for enumerations that are not relevant to the
applications or instances.xsd:annotation or
xsd:documentation elements.Users may wish to place cardinality restrictions on occurrences of
elements in types. By default, most entities are entered as
[0..unbounded] (minOccurs="0",
maxOccurs="unbounded"). Cardinality
restrictions will not invalidate a subset schema. To restrict
cardinality, you may increase the minOccurs value, and
decrease the maxOccurs value. For example:
<xsd:element ref='PersonFullName' minOccurs='0' maxOccurs='unbounded' />
may be restricted to any of the following:
<xsd:element ref='PersonFullName' minOccurs='0' maxOccurs='999' /> <xsd:element ref='PersonFullName' minOccurs='0' maxOccurs='1' /> <xsd:element ref='PersonFullName' minOccurs='1' maxOccurs='1' /> <xsd:element ref='PersonFullName' minOccurs='1' maxOccurs='unbounded' /> <xsd:element ref='PersonFullName' minOccurs='999' maxOccurs='unbounded' /> <xsd:element ref='PersonFullName' minOccurs='1' maxOccurs='2' />
There are a large number of transformations which could be performed on the schema that are not recommended. It is important that the generated schema truly is a subset of the full justice data model schema. Here is a list of changes that should not be performed:
/3.0/jxdm.xsd)| © 2004, The Georgia Tech Research Corporation. All Rights Reserved. |
|
|