The Court's Integration Services are based on a set of schema that as a group we refer to as CourtXML. CourtXML is made up of 3 main types of schema.
- Simple Type Schemas: These schemas contain enumerated simple types that are used to define a list of valid values for a given element or attribute. These schema are never used on their own but are always imported into and used by another schema. Simple Type schemas can change over time as values are added, modified or removed. These changes do not result in versioning upgrades.
- Base Schema: The schema named CourtXML_#.xsd is referred to as our base schema. The # indicates the base schema version number. This schema contains type definitions that are used by other schema when defining messages. Like Simple Type schemas this schema is never used on its own but is always imported into and used by another schema.
- Message Schemas: Schemas that we refer to as Message Schemas define the content of messages that are either input to, or output from, one of our services. Message schemas are named with a suffix containing the base schema version that they are associated to along with the version of the message schema. For example the message schema CriminalComplaintDocument_3_2.xsd references the base CourtXML schema version 3 and is the 2nd version of the CriminalComplaintDocument schema that has been published. The top level element of every message defined within a message schema has an attribute named schemaVersion. This attribute will carry the version number of that message schema. For example messages defined within the message schema CriminalComplaintDocument_3_2.xsd will have "3:2" as their schemaVersion attribute value.
The version of a message schema that is used is driven by the consumer of a particular service.
- For query and e-filing type services the version of the reply and response messages will always match the version of the request and submission message. If a request or submission is made using an inactivated version of a message schema a fault will be returned.
- For notification services the message version that is used is configured into the subscription. This will not change until the consumer makes a request to have it change.
When changes occur that would result in a type change the following steps are taken to prevent breaking existing client code.
- Any types contained in the base schema that require changes are copied and given a new name within that schema. Then the change is made to the type with the new name and an annotation is added to the old type indicated that it has been deprecated. For example a complex-type named ChargeType may need to have a new element added to it for some business reason. A new copy of the ChargeType complex-type would be added to the base schema with the name ChargeType2.
- If an element or type contained within a message schema requires a change, a new copy of that message schema will be created with its message version number incremented and the prior version will be deprecated.