COURT INTEGRATION SERVICES

Court Integration Services enables authorized agencies to exchange information with the Minnesota Judicial Branch.

CourtXML

CourtXML provides a cohesive and consistent view of Minnesota Judicial Branch information in integrating with agency’s systems. 

CourtXML is a cohesive and consistent view of Minnesota justice information for the purpose of integration with Minnesota Judicial Branch consumers.  Providing court data in XML schema permits consumers to readily transform court data into formats and structures appropriate to their business practices and technologies.
Using CourtXML Schema

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:
eFiling 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:  

Schema Name
Production Date
Status*
Deprecated
Inactivated
07/16/2007
supported
 
 
07/16/2007
supported
 
 
02/28/2008
supported
 
 
02/28/2008
supported
 
 
07/16/2007
unsupported
09/20/2012
 
09/20/2012
supported
 
 
09/20/2012
supported
 
 
02/28/2008
supported
 
 
02/28/2008
supported
 
 
09/20/2012
supported
 
 
09/20/2012
supported
 
 
07/16/2007
inactivated
02/04/2010
07/30/2010
 
inactivated
02/04/2010
07/30/2010
02/04/2010
inactivated
02/16/2012
11/02/2013
02/16/2012
inactivated
04/03/2014
01/14/2015
04/03/2014
supported
 
 
04/03/2014
supported
 
 
 
draft
 
 
07/07/2011
supported
 
 
04/03/2014
supported
 
 
04/03/2014
supported
 
 
06/09/2009
supported
 
 
06/09/2009
supported
 
 
02/28/2008
inactivated
02/16/2012
01/14/2015
02/16/2012
inactivated
04/03/2014
01/14/2015
04/03/2014
supported
 
 
04/03/2014
supported
 
 
04/03/2014
supported
 
 
02/28/2008
supported
 
 
02/28/2008
supported
 
 
09/15/2011
inactivated
02/16/2012
07/01/2012
02/16/2012
inactivated
04/03/2014
01/14/2015
04/03/2014
draft
 
 
07/16/2007
supported
09/20/2012
 
09/20/2012
supported
 
 
09/20/2012
supported
 
 
07/16/2007
supported
 
 
07/16/2007
supported
 
 
09/20/2012
supported
 
 
09/20/2012
supported
 
 
07/16/2007
supported
 
 
07/16/2007
supported
 
 
07/16/2007
supported
 
 
07/16/2007
supported
 
 
Notification Schemas

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:

Schema Name
Production Date
Status*
Deprecated
Inactivated
07/16/2007
unsupported
12/13/2007
 
12/13/2007
unsupported
04/03/2014
 
04/03/2014
supported
 
 
03/24/2016
supported
 
 
03/24/2016
supported
 
 
06/06/2005
unsupported
01/01/2006
06/15/2009
01/01/2006
unsupported
07/16/2007
09/15/2011
07/16/2007
unsupported
12/13/2007
 
12/13/2007
unsupported
06/26/2008
 
06/26/2008
unsupported
08/19/2010
 
08/19/2010
unsupported
06/28/2012
 
06/28/2012
unsupported
04/03/2014
 
04/03/2014
supported
 
 
03/24/2016
supported
 
 
03/24/2016
supported
 
 
 
draft
 
 
12/20/2016
supported
 
 
12/20/2016
supported
 
 
Query Schemas
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:

Schema Name
Production Date
Status*
Deprecated
Inactivated
06/06/2005
unsupported
07/16/2007
06/15/2009
07/16/2007
unsupported
12/13/2007
 
12/13/2007
unsupported
06/26/2008
 
06/26/2008
unsupported
08/19/2010
 
08/19/2010
unsupported
06/28/2012
 
06/28/2012
unsupported
04/03/2014
 
04/03/2014
supported
 
 
03/24/2016
supported
 
 
03/24/2016
supported
 
 
01/01/2006
unsupported
07/16/2007
06/15/2009
07/16/2007
unsupported
 
 
03/24/2016
supported
 
 
03/24/2016
supported
 
 
 
draft
 
 
CourtXML Base Schema
     
      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.

Schema Name
Production Date
Status*
Deprecated
Inactivated
06/06/2005
unsupported
07/16/2007
09/15/2011
07/16/2007
unsupported
03/24/2016
 
04/03/2014
supported
 
 
04/03/2014
supported
 
 
03/24/2016
supported
 
 
03/24/2016
supported
 
 
07/16/2007
unsupported
03/24/2016
 
CourtXML Simple Types
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   

RSS Feed

                                                                 
All simple type schema files - chameleon format without enumerations

RSS Feed

                      
All simple type schema files - namespace version 3 format 

RSS Feed

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

RSS Feed


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 
 
CourtXML Simple Type Companion Files
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   
RSS Feed   
Development
All Development simple type schema companion files   
                                                
Test/QA
All Test/QA simple type schema companion files 
Over time schemas will need to be updated and new versions of schemas will be published. Court Integration Services will process messages based on prior versions of schemas for a minimum of 6 months after a new version has been published providing time for consumers to migrate their applications to use the new version.  Please see Versioning Strategy and Policy tab for more details.
 

Update Notification

While current versions of the CourtXML schemas are available in the download section, consumers desiring timely notification of updates may wish to subscribe to the RSS Feed. This RSS Feed provides notification of updated schemas and other documentation. Note: SimpleType schemas and companion files have separate RSS feeds.

RSS Feed

RSS Feed

 

Quick Tip

Many of today's browsers will display the contents of XML documents when you click on a link. If your intent is to download the document, this behavior may interfere with your attempts to download schema documents from this site. If you encounter this problem, merely use your browser's download facilities to download and save a copy of the schema to your local computer. Typically this can be accomplished by right mouse clicking on the link and choose to save the file, e.g., in Internet Explorer this is the "Save Target As..." menu option. This is "cleaner" than copying the schema text from your browser's window which may contain the "+" and "-" signs associated with a tree-view or outline display of the document.
CourtXML Base Schema Versioning
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.
 
Service Schema Versioning
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

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 Schema Versioning

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.
Strategy

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.
Suggested Best Practices
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.
Versioning Support Policy

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.
The Minnesota State Court System has adopted XML technologies as a standard means to receive and disseminate court data electronically. Minnesota State Courts CourtXML serves to describe and catalog this data within an XML schema. CourtXML describes the business domain of information maintained by the courts in a manner that is consistent with the laws, procedures and practices in Minnesota’s trial and appellate courts and how that data is retained in the courts electronic systems. While recognizing and drawing from other efforts to define justice and legal information, e.g., Global Justice XML, LegalXML, the focus of CourtXML is to provide the most concise and accurate presentation of court data which reflects the processing of cases through our courts.

CourtXML is a court centric view of justice information. We recognize that alternate views of this same data exist that may be more suitable to the consumer of our data. Providing court data in XML format with a published CourtXML schema permits consumers to readily transform court data into formats and structures most appropriate to their business practices and technologies.

Several controlling values govern the design and evolution of CourtXML. They include:
  • Fidelity to Minnesota laws, procedures and practices as prescribed by the Minnesota Supreme Court through its inherent powers to regulate the practice of law;
  • Recognition that the source of information is in the best position to cast or present this information into a format most meaningful to and consistent with court functions;
  • Minimize the variants of common information sets, e.g., names, addresses, statutory cites, to provide for efficient processing and presentation of the information;
  • Standardize data structures across substantive areas, again for efficiency;
  • Suitable organization and granularity of data to maximize their reuse allowing for common processing modules;
  • Recognize and adopt external standards and formats for presenting information where consistent with the first value above, e.g., dissemination of warrant information may best be provided in Global JusticeXML structures due to its relevance to justice agencies beyond Minnesota; incoming citation information may best be presented in a format consistent with the promulgating authority (Commissioner of Public Safety).
In turn, we anticipate that all parties will derive the following benefits from applying the above principles:
  • Clear and accurate communication of information due to less need to transform data from uncommon or inappropriate structures;
  • Reasonable, if not best fit to Minnesota court practices and policies used in processing and disseminating information;
  • Stability of data structures consistent with the stability of court business practices;
  • Facilitate the building of both incoming and outgoing court documents by aggregating common data structures;
  • Minimize the amount of coding needed to handle and process common information through the use of common modules acting upon standard data structures;
  • Minimize maintenance of our systems. The proposition is simple - less code, less maintenance.
Revised:08/29/2016