CourtXML is used to support the integration services provided by the Minnesota Judicial Branch.  There are 3 types of services; E-Filing, Query and Notifications, each with their own schema sets.  The CourtXML base schema and Simple Type files are referenced by each of the service schema. 

Setting the Schema location:

After the schemas are downloaded, you may need to modify the schemas to fit within your file structure.  The schemas expect the following file structure:

CourtXML Base Schema and Message Schemas located in the same folder.

SimpleType schemas located in a subfolder (of the folder containing the Base and Message schemas) named SimpleTypes.

If you want to keep these files in a different structure you need to make changes to the schema include and import statements that reference other schemas. For example:

 <xs:include schemaLocation="CourtXML_3.xsd"/>

 Will expect the schema CourtXML_3.xsd to be found in the same folder as the schema with the include statement.

 <xs:include schemaLocation="c:\schemas\CourtXML_3.xsd"/>

 Will expect the schema CourtXML_3.xsd to be found in the folder c:\schemas.

 Note: the same applies to any other schemas that are included or imported, such as the SimpleType schemas.

Here are the 5 different classifications of CourtXML schemas:

The eFiling Schemas are used to support eFiling Services. The eFiling Services page has links to the specific services described below. 
The eFiling Services below each have their own schema currently in use:  

Notification Schemas are used to support Notification Services. There are three Notification services which have their own CourtXML schema: Case Notification, Bond Notification, and Party Notification. Our Document Notification service uses the format specified by Electronic Court Filing (ECF) 4.0.
The schema currently in use include:

Query Schemas are used to support Query Services.  The two query services, Case Get and Case Search by Party, each have their own schema.  The schema currently in use include:

     
      A single schema file named CourtXML_#.xsd, where # corresponds to the version, which contains the types that are used to build the messages used by Court Integration Services.

The CourtXML Simple Type schemas provide current allowable values for various element values within each of the service schema and the CourtXML Base schema.  These simple types are frequently updated through a process of MNCIS data extracts and no previous versions are retained.  To keep your simple types current, it is necessary to subscribe to updates or to regularly download new copies of the simple type schema.

CourtXML Simple Type schema are provided in 3 different formats; Chameleon, Namespace, and Namespace without Enumerations. The Chameleon format does not specify a namespace or target namespace. When the chameleon format schema are imported into another schema, they take on the namespace of the importing schema. This allows these schema to be used with any version of CourtXML.

Namespace format is provided that specifies a namespace and target namespace since not all xml tools are able to use chameleon schemas. Chameleon format and Namespace format are the same other than the namespace declarations. Either can be used depending on the needs of your tools.

The Namespace without Enumeration format specifies the namespace, but doesn't contain any enumeration values. You may choose to use this set if your development tool has problems with loading the large numbers of enumeration values or because the enumeration values can change over time, causing issues with your development. The only changes that should happen to this set is that new simple types could be added, or changes could be made to their annotations.

These files are updated when configuration changes are made to MNCIS. After your initial download you may want to subscribe to the RSS feed for the set of simple type files that you are using by clicking on the associated XML/RSS link.

Simple Type Schema File Downloads

Production  

All simple type schema files - chameleon format   

                                                                 
All simple type schema files - chameleon format without enumerations

                      
All simple type schema files - namespace version 3 format 

                                                 
All simple type schema files - namespace version 3 format without enumerations

Dev and QA Simple Type File Downloads 
    
The court has 2 non-production environments that are used for development and testing. If you need to interact with these environments as a part of the development of your integrations, the following links and RSS feeds will provide you with versions of the simple type schemas and companion files that correspond to them.
                                                                 
All Development simple type schema files - chameleon format 
All Development simple type schema files - chameleon format without enumerations
All Development simple type schema files - namespace version 3 format
All Development simple type schema files - namespace version 3 format without enumerations 
     
All Test/QA simple type schema files - chameleon format 
All Test/QA simple type schema files - chameleon format without enumerations
All Test/QA simple type schema files - namespace version 3 format 
All Test/QA simple type schema files - namespace version 3 format without enumerations 
 

These files are xml documents that are each paired with a simple type schema file and contain the enumeration values from that schema and associated code, description, effective date and obsolete date. Some contain additional values that may be useful when using a SimpleType schema. These files are intended to be more programmatically useful than the simple type schema files for applications that are performing functions such as providing options to users that match the values in the simple types.

Some simple type schemas contain values that are specific to only one court or a subset of courts. For these simple type schemas the associated companion file contain an an additional value (type=CourtJurisdictionORI) that provides the ORI for the court that the value applies to. This value can be used to restrict the choices to only those that apply to the court that is either the source or destination of a message. Some examples of simple types that contain this attribute are: CourtCalendarNameTextType, CommunityOfOffenseTextType, HearingLocationTextType and HearingSessionTypeTextType.

These files are updated when configuration changes are made to MNCIS. After your initial download you may want to subscribe to the RSS feed for these files that by clicking on the associated XML/RSS link.

Companion File Downloads    

Production       
All simple type schema companion files   
  
Development
All Development simple type schema companion files   
                                                
Test/QA
All Test/QA simple type schema companion files 

Several of our services are built with the intent to use the format specified by Electronic Court Filing (ECF) 4.0. We do not always have the exact message we need, or information we need though, which is why we have created the following message and extension schema.

 

The name of the CourtXML base schema (CourtXML_#.xsd) incorporates a number which corresponds to the high level version of CourtXML with which you are working. The CourtXML schema can have changes made to it without causing this number to be incremented. The following types of changes fall into this category:

• Additions of new simple or complex types. Note: if an existing type needs to be modified in some way a copy of that type will be made and it will be added as a new type to the schema with a number added to its name. This, or the addition of any other new simple or complex type will not affect any existing services since they will not have been used yet.
• Updates to annotations.
• Some minor changes to existing types where the impact of the change on consuming applications should be minor (such as adding an optional attribute or element, or adding a constraint that allows the schema to enforce a validation rule that is already being enforced elsewhere).

When changes are made to a published version of a CourtXML base schema (for example CourtXML_3.xsd) for any of the types of changes described above the following updates will also be made:

• An annotation will be added to the beginning of the schema that describes the change.
• The value of the version attribute of the schemas xs:Schema element will be incremented.

When a new version of the CourtXML base schema is published the number within its name will be incremented (CourtXML_3.xsd to CourtXML_4.xsd) and its internal version attribute value will be set to 1.
 

The name of a service schema incorporates numbers which correspond to the version of the CourtXML base schema that this schema is associated with and the version of the service schema at that CourtXML base schema level. For example the name CriminalComplaintDocument_3_2.xsd represents the 2nd version of the CriminalComplaintDocument schema that is associated with CourtXML_3.xsd. The general format is:
     <schema-name>_#1_#2

• #1 corresponds to the CourtXML schema and
• #2 corresponds to the version of the service schema.

 Service schemas can have changes made to them without causing the version numbers to be changed. The following type of changes fall into this category:

• Additions of new elements, simple types and complex types.
• Updates to annotations.

When changes are made to a published version of a service schema (for example CriminalComplaintDocument_3_1.xsd) for any of the types of changes described above the following updates will also be made to it:

• An annotation will be added to the beginning of the schema that describes the change.
• The value of the version attribute of the schemas xs:Schema element will be incremented.

When a new version of a service schema is published that is using the same version of the CourtXML base schema the service schema version number will be incremented (CriminalComplaintDocument_3_2.xsd to CriminalComplaintDocument_3_3.xsd). When a new version of a service schema is published that is associated with a new CourtXML base schema the CourtXML schema number will be changed and the service schema number will be set to 1 (CriminalComplaintDocument_3_3.xsd to CriminalComplaintDocument_4_1.xsd).

Objectives

• Enable the court to evolve the schema due to business or technical changes.
• Provide support for prior versions of schemas.
• Minimize the impact of schema changes to integration partners.
• Keep the number of supported schema versions down to a manageable number.
• Eliminate the need for integration partners to make unnecessary changes to their applications due to new schema versions.
• Give our partners as much time as possible to react to schema changes.
• Define a mechanism to gracefully phase in new schema versions and phase out old versions.

 
This strategy is intended to address these concerns:

• Partner may not be able to update their applications on the same schedule that the Court implements a schema change - we need a way to prevent schema changes from breaking client code
• As the number of schema versions increases, support becomes more difficult - the Court needs a way to keep the number of supported schema versions to a level that can be supported
• Partner application changes cannot be made on short notice - the Court needs to provide as much notice as possible before a schema version is inactivated, and support for prior versions for some period of time

 
Why are schema changes necessary?

• As XML schema constructs are typed, any modification that would result in a type change is a potential incompatibility. For example, we might currently express a measurement or a count in integer values (xs:int), but in a future enhancement we might need a way to allow decimal fractions for the same value (xs:double). If your application is expecting a field to return an integer at runtime and we start returning a double instead, your application could fail. So, we need a way to avoid changing the type directly.
• Another example of a type change would be adding an element to an existing complex-type. If this new element is required and your client application does not include it, or expect it in a response that client application could fail. A similar problem would occur when removing an element.
• Changing the multiplicity of an element is also a potential incompatibility. For example, we might currently allow a single Name element, but in a future enhancement we might allow repeating Name elements (maxOccurs="unbounded"). As some toolkits interpret repeating fields as arrays, this would be equivalent to a type change.
• Note: We try to avoid making purely cosmetic changes to schemas that would break client code.

Simple Type Schemas do not have any version numbers associated with them, either in their names or version attributes. These schemas contain SimpleType definitions and the only changes that could be made to them are to their enumerated values. These enumerated values generally represent codes within one of the courts applications and are automatically updated as these codes are updated. The only indicator as to the version of a Simple Type Schema is an annotation that provides the date and time that the schema was last refreshed.

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.

The following best practices are suggested for use of message schema versions:

• Use supported versions. As a part of your applications normal maintenance schedule attempt to keep it current with using only supported versions of message schemas. This provides the greatest likelihood that system changes will not negatively impact your application (because of regression testing) and assures that the support that you receive from the court will be at its highest level.
• When you have a need to change your application for some reason also migrate to the current version of any message schemas that are being used. If your application has fallen behind more than one version there is no need to migrate to the intermediate versions.
• For new development always use the current schema version.
• Monitor the Court Integration Services website, and Integration Services update notification emails for changes to the support status of message schemas. When a new version of a schema is published and an old version is deprecated, or when a version is slated to be inactivated, the change in status for that schema will be reflected on the CourtXML schema web page and will be announced in an Integration Services update email.
• Design your software to be able to handle, or gracefully ignore, new elements that we add to the schema. This will simplify migration to a new version.
• Make the schema version a configuration setting so if a new version does not change anything that is being used then migration to a new version only requires a configuration change.

The support status of message schemas will fall into 5 categories.

•Draft: These include schemas that are still being developed and being reviewed both internally and by partners.  These schemas are likely to change before implementation.

•Pre-Release: These include schemas that have not been published in production yet. Generally these will be available for testing in our development environment though they may be still considered in a draft state.

•Supported: These include schemas that are the current version, the prior version or any prior version that has been deprecated within one year. These schemas are fully supported. Full support includes the following: 
 

• When regression testing is done all supported schemas for a particular service are tested.
• Issues that are identified with a service and a supported version of the schema receive the highest priority for troubleshooting and resolution.
• Documentation for a particular service will always reflect the current version of its message schema.

 •Unsupported: These include schemas that have been deprecated for more than a year and are not the prior version to a current schema. Unsupported means the following:
   

• This message schema version is still available for use.
• Any regression testing that is done will not include this version of the schema.
• Issues that are identified with a service and an unsupported version of the schema will have a lower priority for troubleshooting and resolution, and depending on the problem may not be corrected. (The resolution may involve the partner migrating to the current version of the schema).

 •Inactivated: These include versions of message schemas that can no longer be used. Message schemas will generally not be inactivated unless there is a particular reason to do so, such as a business change that makes them either not support the current business process, causes them to inaccurately represent their area of court information, or are no longer used by any consumers. We will attempt to provide a minimum of 6 months notice when a version of a message schema is about to become inactivated.