MoCDEx-IEPD-Master-Document-v1

stizzahaddockΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

81 εμφανίσεις


Purpose and Scope

In support of OSCA’s data standardization initiative through the Justice Information System (JIS), this
document is intended to assist Missouri justice offices that are filing criminal or traffic cases electronically
to the JIS Case Mana
gement System. This electronic filing known as an exchange utilizes the National
Information Exchange Model (NIEM). The exchange standardizes the data elements and their
relationships which can be sent electronically. The exchange is exposed using web se
rvices implemented
with SOAP version 1.1.


Terms and Standards


National Information Exchange Model (NIEM) 2.1

NIEM is a federally
-
supported, government
-
wide initiative that helps communities of people with common
mission interests connect and exchange inf
ormation in order to successfully and efficiently accomplish
their missions. NIEM is not a system or database; nor does it transmit, store, or otherwise engage in
operational data sharing. Rather, NIEM provides many tools, the training, and community
-
drive
n support
needed to assist users in adopting a standards
-
based approach to exchanging information.

NIEM makes it possible for organizations at several different levels and jurisdictions to share critical data,
empowering individuals to make informed decisi
ons that improve efficiency and help advance missions
goals. NIEM is designed to enable government to address the challenge of connecting government
agencies utilizing the appropriate business and security policies by providing a common vocabulary and
mat
ure framework to facilitate information exchange. NIEM enables diverse communities to “speak the
same language” as they share, exchange, accept, and translate information efficiently.

NIEM focuses on the development of shared services using cross
-
boundary

information exchange across
multiple levels of government. In this way, NIEM breaks down agency stovepipes and creates the
opportunity for agencies to share information quickly and effectively without completely rebuilding
systems. NIEM is technology agn
ostic and addresses the format of data as it is shared between systems.
This allows communities of interest to collectively leverage NIEM irrespective of the particular
technologies used within any individual organization. This approach enables agencies to

keep systems
compartmentalized and ensure appropriate safeguards while at the same time wrapping them with a set
of standardized exchanges, an appropriate policy framework, and an appropriate security model.

NIEM 2.1 is the latest release of this framewor
k technology.

Detailed information on NIEM can be found at
https://www.niem.gov
.


Simple Object Access Protocol (SOAP) 1.1

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed envir
onment. It
is an XML based protocol that consists of three parts: an envelope that defines a framework for
describing what is in a message and how to process it, a set of encoding rules for expressing instances of
application
-
defined datatypes, and a conve
ntion for representing remote procedure calls and responses.
SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings
defined in this document describe how to use SOAP in combination with HTTP and HTTP Exten
sion
Framework.

The specification can be found at
http://www.w3.org/TR/2000/NOTE
-
SOAP
-
20000508/


Web Services RPC (WS
-
RPC)

Web services are a system design feature allowing for interoperable app
lication interaction over a
network. Typically, web service exchange XML messages using a networking protocol known as TCP.
When a web service transport the message of HTTP and is incorporated with WSDL, defined later, and
SOAP a web service can be struc
tured to execute processes on the remote application. WS
-
RPC may
ignore existing capabilities of HTTP such as Basic Authentication and implement security via WSS which
is described later.


Web Services Definition Language (WSDL) 1.1

WSDL is an XML
-
based
language that is used for describing the functionality offered by a Web service.
WSDL provides a machine
-
readable description of how the service can be called, what parameters it
expects, and what data structures it returns. It thus serves a roughly simila
r purpose as a method
signature in a programming language.

The latest release of the the WSDL specification is 2.0. The meaning of the acronym "D"
-

Definition, has
changed from version 1.1 to Description. The WSDL describes services as collections of net
work
endpoints, or ports. The WSDL specification provides an XML format for documents for this purpose. The
abstract definitions of ports and messages are separated from their concrete use or instance, allowing the
reuse of these definitions. A port is def
ined by associating a network address with a reusable binding, and
a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged,
and port types are abstract collections of supported operations. The concrete protoc
ol and data format
specifications for a particular port type constitutes a reusable binding, where the operations and
messages are then bound to a concrete network protocol and message format. In this way, WSDL
describes the public interface to the Web ser
vice.

WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the
Internet. A client program connecting to a Web service can read the WSDL file to determine what
operations are available on the server. Any special datatyp
es used are embedded in the WSDL file in the
form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the
WSDL file using XML or HTTP.


Web Services Addressing (WS
-
Addressing, WS
-
A) 1.0
-

WSDL Binding

WS
-
Addressing
is a specification of transport
-
neutral mechanisms that allow web services to
communicate addressing information. It essentially consists of two parts: a structure for communicating a
reference to a Web service endpoint, and a set of Message Addressing Pro
perties which associate
addressing information with a particular message.

WS
-
Addressing is a standardized way of including message routing data within SOAP headers. Instead of
relying on network
-
level transport to convey routing information, a message util
izing WS
-
Addressing may
contain its own dispatch metadata in a standardized SOAP header. The network
-
level transport is only
responsible for delivering that message to a dispatcher capable of reading the WS
-
Addressing metadata.
Once that message arrives at

the dispatcher specified in the URI, the job of the network
-
level transport is
done. WS
-
Addressing supports the use of asynchronous interactions by specifying a common SOAP
header (wsa:ReplyTo) that contains the endpoint reference (EPR) to which the resp
onse is to be sent.
The service provider transmits the response message over a separate connection to the wsa:ReplyTo
endpoint. This decouples the lifetime of the SOAP request/response interaction from the lifetime of the
HTTP request/response protocol, th
us enabling long
-
running interactions that can span arbitrary periods
of time.


WS
-
Security (WS
-
S, WSS) 1.1

WSS describes enhancements to SOAP messaging to provide quality of protection through message
integrity, message confidentiality, and single message

authentication. These mechanisms can be used to
accommodate a wide variety of security models and encryption technologies. WS
-
Security also provides a
general
-
purpose mechanism for associating security tokens with messages

http://www.oasis
-
open.org/committees/download.php/16782/wss
-
v1.1
-
spec
-
os
\
-

http://www.oasis
-
open.org/committees/download.php/16782/wss
-
v1.1
-
spec
-
os
-
UsernameTokenProfile.pdf
UsernameTokenProfile.pdf


WS
-
P
olicy (WS
-
P) 1.5

WS
-
P is an interoperability standard that is used to describe and communicate the policies such as WS
-
A
and WS
-
S of a Web service so that service providers can export policy requirements in a standard format.
The policy configuration can
be shared in the published WSDL. A policy represents the capabilities and
requirements of a web service, for example, whether a message is secure and how to secure it, and
whether a message is delivered reliably and how this is achieved.

The specification

can be found at :
http://www.w3.org/TR/2007/REC
-
ws
-
policy
-
20070904/
.


Secure Socket Layer (SSL)

SSL is the standard security technology for establishing an encrypted link between TCP networ
ked
applications. This link ensures that all data passed between the applications remain private. SSL is an
industry standard and is used by millions of websites in the protection of their online transactions with
their customers.This encryption is obtain
by use of cryptographic keys
-

a Private Key and a Public Key.
The public key is used to encrypt information and the private key is used to decipher it. The SSL
negotiation starts by the client requesting the server to identify itself. The server then s
ends the client a
public key. The client determines whether it trusts the certificate. If so, it sends a message back to the
server containing it public key. The server then send back a digitally signed acknowledgement to start
SSL communication. Upon
agreeing on the type of encryption to use the client and server will then
exchange unique public encryption keys used to encrypt the data. Each maintains a unique private key
to decrypt the messages receipt from the other. If the client can successfully
decrypt the message an
encrypted communication is begun. The process is nearly identical when encrypting data using HTTPS.
The difference being that an additional port (443) is utilized to transport encrypted messages allow with
the HTTP port which by de
fault is port 80.


Exchange Provisions


Exchange Descriptions

MoCDEx utilizes web service to present services provided by multiple agencies. The MoCDEx_V... wsdl
defines the services to be implemented by the Missouri state courts. The CourtResponse...wsd
l decribes
the services to be implemented by the Missouri Prosecutor Service vendor and is utilized by the courts to
return filing information to participating prosecutor offices.

The exchange communications are encrypted by SSL via and endpoint on an HTTP
S address. The
exchange HTTPS address will utilize certificates managed by Verisign, Inc. It is assumed the key pair
will be trusted without the need to be manually added to the clients keystore. These certificates do
expire and appropriate measures s
hould be taken to alleviate any down time which may result when new
certificates are put into place.

Exchange data submissions are subject to client authentication. The exchange implements a WS
-
Security UsernameToken policy. The client's username and pas
sword pair are maintained by OSCA and
are awarded upon entering into a client certification period. The client's username password pair is valid
for the exchanges certification site. This site is used to verify the clients can successful transmit valid
e
xchange messages. The a new password is then assigned to the the client and the client location is
granted authority to submit messages to the production exchange. If at anytime the client location
submits messages which in the site administrator opinion

may adversely affect the integrity of the
exchange the client password will be reset. The client will then need to re
-
certify their ability to
successfully participate in the exchange.

The MoCDEx WSDL and MoCDEx Exchange Schema should accommodate both Cr
iminal Filings by the
Prosecutors as well as Traffic Tickets sent by MSHP or other Law Enforcement to FCC or the courts.

fileCriminalCase
-

PA to Court
-

submitting an intial filing of a criminal case

fileTrafficCase
-

PA to Court or MSHP/LE to Court/FCC
-

submitting of one or more traffic case to be filed
in the court or FCC

fileSubsequentFiling
-

FUTURE
-

PA to Court
-

submission of subsequent filings on a case to the court
after the court has initiated the case

withdrawCriminalFiling
-

FUTURE
-

cancel th
e previous fileCriminalCase operation prior to the case being
accepted by the court

withdrawTrafficFiling
-

FUTURE
-

VOID the traffic ticket submission prior to the a written guilty plea and
not guilty plea

submitFilingValidationErrors
-

FUTURE
-

post pro
cessing validation errors prior to the case being accepted
by the court or FCC

getCourtResponse
-

request from PA, MSHP/LE for the court case id and next hearing date for case filed
through the service, this is in addition to the Court Response submitted t
o the Karpel system

isAvailable
-

used by monitoring software to check availability

Currently the Missouri State Courts endpoint
is:
https://www.courts.mo.gov/webservices/m
ocdex/services/MoCDExv1_0


XML Schemas

The data Criminal Initial Filing initiative relies on XML data files and schema to exchange data in a
standard way.

For justice professionals not familiar with XML, it is a fairly straightforward and flexible way of
expressing
data and is especially helpful in managing large documents that are frequently revised and need to be
printed in different formats.
XML

(short for Extensible Markup Language) is a system for organizing and
tagging elements of a document. XML its
elf does not specify any particular formatting; rather, it specifies
the rules for tagging elements. Designed especially for Web documents, XML allows designers to create
their own customized tags, enabling the definition, transmission, validation, and int
erpretation of data
between applications and between organizations.

The XML filing process uses
schema

--

a model for describing the
structure

of information
--

to describe
and validate data in an XML environment. In particular, the project uses XML schema

known as XSD
(short for XML Schema Definition) files.

XSD is written in XML and defines a set of data types such as Booleans, numbers, dates and times, and
currencies
\
\

which is helpful for justice case
-
management applications (among other things).

XSD v
alidates documents based on namespaces. A
namespace

is a collection of names that are used in
XML documents as element types and attribute names. Namespaces prevent identically custom
-
named
tags that may be used in different XML documents from being read t
he same way.


Exchange Message Structure

These following description details the MoCDEx_V... WSDL and two schemas MoCDEx Exchange schema
and the MoDEX schema. The CourtResponse WSDL is defined by a seperate IEPD maintained by Karpel
Software Solutions.

Th
e MoCriminalDataExchange.xsd schema is the structured data of the exchange it is mapped in the
MoCDEx Global Data Elements.xls spreadsheet which is included as well.

The second schema is the MoExchangeDocument.xsd schema. It's purpose is to add metadata t
o each
structured data submission.

This schema has a root element of MoExchangeMessage.

The MoExchangeMessage would be used in data transports other than SOAP/WSDL 1.1 implementation.

From the this root there are two element on a switch MoExchangeRequest

and MoExchangeResponse.

The MoExchangeMessage element will not be utilized in the MOCDEx exchange WSDL. The MoCDExv1_0
WSDL operations have individual request and response signature elements. These element then contain
either the MoExchangeRequest or th
e MoExchangeResponse.

The MoExchangeRequest element contains MoExchangeHeader, MoExchangeStructuredDataPayload and
MoExchangeNotification.

MoExchangeNotification will not currently be used for the MoCDEx exchange but it's intention is to
provided to the ho
st a list of return notifications. MoExchangeStructuredDataPayload contains
MoExchangeStructuredData which is repeatable. The MoExchangeStructuredDataPayload will be filed in
the county denoted in the header element DestinationLogicalName. Currently onl
y a few of the
MoExchangeHeader elements will be utilized in the exchange.

/mo
-
doc:MoExchangeRequest/mo
-
doc:MoExchangeHeader/

HeaderVersion, ServiceName, ServiceVersion, TransactionName, DestinationLogicalName, SourceORI and
CreationTimestamp

<HeaderVersio
n>1.0</HeaderVersion>

<ServiceName>MoCDEx</ServiceName>

<ServiceVersion>1.0</ServiceVersion>

<TransactionName>CriminalInitialFiling</TransactionName>

<DestinationLogicalName>BNE</DestinationLogicalName>

<SourceORI>ORI of PA office sending message</SourceOR
I>

<CreationTimestamp>2011
-
11
-
08T13:30:00.00000</CreationTimestamp>

The MoExchangeResponse element contains the same elements as the MoExchangeRequest element
withe addition of the MoExchangeException element.

For the purposes of the MoCDEx exchange the Mo
ExchangeDocument schema will be used as an in
-
line
schema in the WSDL. Each WSDL operation has an individual request and response signature element.
The operations defined above with the exception of the isAvailable operation will have a
MoExchangeRequest

element as an element in the in bound signature element and a
MoExchangeResponse element as an element of their signature out bound element.

The XML payload document provided in the /mo
-
doc:MoExchangeRequest/mo
-
doc:MoExchangeStructuredDataPayload/MoExchan
geStructuredData element of the request will be UTF
-
8
encoded or enclosed within the XML schema CData type for transport to the provider.

The message receipt will be provided back to the consumer in the /mo
-
doc:MoExchangeResponse/mo
-
doc:MoExchangeStructure
dDataPayload/MoExchangeStructuredData element. It will not by UTF
-
8
encoded. If validation errors are encountered upon initial processing of the message no receipt will be
provided and the MoExchangeException will be populated with MoExchangeBusinessExce
ption (s), one for
each validation error. If an exchange error code is established for a given validation it will be populated
in the ExceptionCode and ExceptionMessageText will be populated with the error description.



Documentation Conventions


Attribu
te Descriptions

Attributes defined within a class will have a camel cased name similar to the name found in the GDEL,
optionally, the name will be predicated with either a "
" or "
-
" representing whether the attribute is public
or private respectively. If
not present the default is public. The attribute is followed by it's data type, it's
max length, which can be prefixed with a "
" if the length is the required length. If the attribute or
method is not optional it's cardinality is enclosed with "
\
[ ...
\
]". The final declaration is encapsulated
within "( ... )" and gives a format mask, precision or either a list of values or a "namespace" notation.

\
-
FilingPriorPersistentOffenderCode : String,
\
+5,
\
[1
\
] (namespace)


Relationship annotations


Associat
ion

Class diagram example of association between two classes

An
association

represents a family of links. Binary associations (with two ends) are normally represen
ted
as a line. An association can be named, and the ends of an association can be adorned with role names,
ownership indicators, multiplicity, visibility, and other properties.

There are four different types of association: bi
-
directional, uni
-
directional,

Aggregation (includes
Composition aggregation) and Reflexive. Bi
-
directional and uni
-
directional associations are the most
common ones.

For instance, a flight class is associated with a plane class bi
-
directionally. Association represents the
static relat
ionship shared among the objects of two classes. Example: "department offers courses", is an
association relation.


Aggregation



Class diagram showing Aggregation between two classes

Aggregation

is a variant of the "has a" or association relationship; aggregation is more specific than
association. It is an association that represents a part
-
whole or part
-
of relationship. As a type of
association, an aggregation can
be named and have the same adornments that an association can.
However, an aggregation may not involve more than two classes.

Aggregation

can occur when a class is a collection or container of other classes, but where the contained
classes do not have a st
rong
life cycle dependency

on the container
---
essentially, if the container is
destroyed, its contents are not.

In
UML
, it is graphically represented as a
hollow

diamond shape

on the containing class end of the tree
with lines that connect contained classes to the containing class.


Composition



Class diagram showing Composition between two classes at top and Aggregation between two
classes at
bottom

Composition

is a stronger variant of the "owns a" or association relationship; composition is more specific
than aggregation.

Composition

usually has a strong
life cycle depe
ndency

between instances of the container class and
instances of the contained class(es): If the container is destroyed, normally every instance that it
contains is destroyed as well. (Note that, where allowed, a part can be removed from a composite before

the composite is deleted, and thus not be deleted as part of the composite.) With composition
(aggregation), an arrow points to the contained class, and the black diamond points towards the
container class.

The UML graphical representation of a compositio
n relationship is a
filled

diamond shape on the
containing class end of the tree of lines that connect contained class(es) to the containing class.


Differences between Composition and Aggregation

When attempting to represent real
-
world whole
-
part relation
ships, e.g., an engine is a part of a car, the
composition relationship is most appropriate. However, when representing a software or database
relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is
best, as t
he engine, ENG01 may be also part of a different car model. Thus the aggregation relationship
is often called "catalog" containment to distinguish it from composition's "physical" containment.

The whole of a composition must have a multiplicity of 0..1 or
1, indicating that a part must belong to
only one whole; the part may have any multiplicity. For example, consider University and Department
classes. A department belongs to only one university, so University has multiplicity 1 in the relationship.
A unive
rsity can (and will likely) have multiple departments, so Department has multiplicity 1..*.


Attribute Optionality

When an attribute has optionality other than optional an additional suffix
\
[1
\
] will be present.


Business Rules

NIEM make use of the XML sc
hema element attribute "type" to implement inheritance. The attribute
"type" must refer to a XML Schema SimpleType of a complex type defined in the schema. NIEM make
use of the attribute "id" and "ref" in XML Schema to enforce data association and to redu
ce data
duplication in the XML document. The attribute "id" must contain a string which is unique throughout the
XML document. The attribute "ref" can only contain the id of and element type allowed by the schema or
by business rules.


Attribute Length
Constraints



Property Name


XPath


Max Length


Court Location
Code

/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseCourt/

j:CourtDivisionText


2


Case Level
Security


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/


j:CaseAugmentation/

j:CaseSecurityText


1


Prosecutor Case
Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseProsecutionAttorney/

j:CaseOfficialCaseIdentification/

nc:IdentificationID


2000




Case Type


/
mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseCategoryText


10


Law
Enforcement
Case Number


/mo
-
cdex:MoCriminalDataExchange/

nc:Metadata/

nc:AdministrativeID

where

/mo
-
cdex:MoCriminalDataExchange/

nc:Metadata/nc:ReportingOrganization
Text = "LE"

AND

the ChargeIncident s:metadata attribute references a Metadata
element

/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
\
[1
\
]/

mo
-
cdex
-
ext:ChargeIncident/@s:metadata


20


Law
Enforcement
Tracking Number


/mo
-
cdex:MoCriminalDataExc
hange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

nc:ActivityIdentification/nc:IdentificationID


2000


Traffic or
Boating Location


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

nc:IncidentLocation/

nc:Loc
ationDescriptionText


78


Neighborhood
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

j:IncidentAugmentation/

j:IncidentArrest/

mo
-
cdex
-
ext:Booking/

j:BookingDetentionFacility/

nc:FacilityLocation/

nc:Loc
ationLocale/


5

nc:LocaleNeighborhoodName


Arresting
Agency ID


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

j:IncidentAugmentation/

j:IncidentArrest/

j:ArrestAgency/

nc:OrganizationPrimaryContactInformation/

nc:ContactEntity/

mo
-
cdex
-
ext:Organization/

j:OrganizationAugmentation/

j:OrganizationORIIdentification/

nc:IdentificationID


9


Offense Cycle
Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
\
[i
\
]/

mo
-
cdex
-
ext:PersonAugmentation/

j:P
ersonAFISIdentification/

nc:IdentificationID


2000


Officer Badge
Number


/mo
-
cdex:MoCriminalDataExchange/

j:Citation/j:CitationIssuingOfficial/

j:EnforcementOfficialBadgeIdentification/

nc:IdentificationID

AND/OR

if there is an arrest

/mo
-
cdex:
MoCriminalDataExchange/mo
-
cdex
-
ext:Incident/

j:IncidentAugmentation/

j:IncidentArrest/

j:ArrestOfficial/

j:EnforcementOfficialBadgeIdentification/

nc:IdentificationID

NOTE multiple values are allowed


2000


Booking District
ORI


/mo
-
cdex:MoCrimin
alDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

j:IncidentAugmentation/

j:IncidentArrest/mo
-
cdex
-
ext:Booking/

mo
-
cdex
-
ext:BookingAgency/

j:OrganizationAugmentation/

j:OrganizationORIIdentification/

nc:IdentificationID/text()


9


Booking Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
\
[i
\
]/

mo
-
cdex
-
ext:ChargeIncident/

j:IncidentAugmentation/

j:IncidentArrest/

mo
-
cdex
-
ext:Booking/

j:BookingAgencyRecordIdentification/

nc:IdentificationID


30


Uniform Citation
N
umber


/mo
-
cdex:MoCriminalDataExchange/

j:Citation/nc:ActivityIdentification/

nc:IdentificationID


15


Posted Speed


/mo
-
cdex:MoCriminalDataExchange/


2

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

mo
-
cdex
-
ext:DrivingIncident/

j:DrivingIncidentL
egalSpeedRate/

nc:MeasureText



Clocked Speed


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

mo
-
cdex
-
ext:DrivingIncident/

j:DrivingIncidentRecordedSpeedRate/

nc:MeasureText



3

Detection Method

/mo
-
cdex:Mo
CriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

mo
-
cdex
-
ext:DrivingIncident/

mo
-
cdex
-
ext:DrivingIncidentDetectionMethodText

6


Prosecutor Type


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseProsecut
ionAttorney/

j:CaseOfficialRoleText/text()


3


Prosecutor Bar
Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseProsecutionAttorney/

j:JudicialOfficialBarMembership/

j:JudicialOfficialBarIdentification/

nc:Iden
tificationID


6


Last Name


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonName/

nc:PersonSurName


60


First Name


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonName/

nc:PersonGivenName


15


Middle Name


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonName/

nc:PersonMiddleName


15


Suffix


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonName/

nc:PersonNameSuffixText


4


Address Type
Code


/mo
-
cdex:MoCriminalDataExchan
ge/

nc:Location
\
[i
\
]/

nc:LocationCategoryText


2


Address Street
Address


/mo
-
cdex:MoCriminalDataExchange//

nc:LocationAddress
\
[i
\
]/

nc:Location
[i]
/


30

nc:StructuredAddress/

ncLocationStreet/

nc:StreetFullText


Address City


/mo
-
cdex:MoCrim
inalDataExchange//

nc:Location[i]/

nc:LocationAddress
\
[i
\
]/

nc:StructuredAddress/

ncLocationStreet/

nc:LocationCityName


20


Address State


/mo
-
cdex:MoCriminalDataExchange//

nc:Location/

nc:LocationAddress
\
[i
\
]/

nc:StructuredAddress/

ncLocatio
nStreet/

nc:LocationStateUSPostalServiceCode


2


Address Zipcode


/mo
-
cdex:MoCriminalDataExchange//

nc:Location/

nc:LocationAddress
\
[i
\
]/

nc:StructuredAddress/

ncLocationStreet/

nc:LocationPostalCode


10


Person Race


/mo
-
cdex:MoCriminalDataE
xchange/

mo
-
cdex
-
ext:Person[j]/

nc:PersonRaceText


2


Person Sex


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonSexCode


1


Person Height


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
[i]
/

nc:PersonHeightMeasure/

nc:Mea
sureText


3


Person Weight


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person[i]/

nc:PersonWeightMeasure/

nc:MeasureText


3


Person Drivers
License Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
[i]
/

mo
-
cdex
-
ext:PersonAugmentatio
n/

nc:DriverLicense/

nc:DriverLicenseIdentification/

nc:IdentificationID


20


Person State of
Drivers License
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
[i]
/

mo
-
cdex
-
ext:PersonAugmentation/

nc:DriverLicense/

nc:DriverLicenseIdentif
ication/

nc:IdentificationJurisdictionText


2


Person Alias
Middle Name


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
[i]
/

mo
-
cdex
-
ext:PersonAlternateName/

nc:PersonMiddleName


15


Person SSN


/mo
-
cdex:MoCriminalDataExchange/


9

mo
-
cdex
-
ext
:Person[i]/

nc:PersonSSNIdentification
[j]



Person Local
Identification
Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person[j]/

nc:PersonOtherIdentification[i]/

nc:identificationID

WHERE

/mo
-
cdex:MoCriminalDataExchange/

/mo
-
cdex
-
ext:Pe
rson[j]/

nc:PersonOtherIdentification[i]/

nc:IdentificactionSourceText = 'LID'


20


Violation
Number


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
[i]
/

j:ChargeSequenceID


3

Missouri Charge
Code



/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
[i]
/

j:ChargeSanction/nc:ActivityIdentification/

nc:IdentificationID


10



JIS NCIC
Modifier


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge[i]/

j:ChargeNCICCode


2


Charge
Description


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ex
t:Charge
[i]
/

j:ChargeDescriptionText


120




In the Alternate


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge[i]/

mo
-
cdex
-
ext:ChargeOriginalSequenceIdentification/

nc:IdentificationID

Contains the sequence number for the Charge
\
[j
\
] for which

this is the
alternate.

The alternate count will be the count if the value of


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge[i]/

mo
-
cdex
-
ext:AlternativeChargeIndicator


3




Charge Text


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
[i]/

j:ChargeEnhancingFactor/

j:ChargeEnhancingFactorDescriptionText


???




Filing Document
Format Type


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseFiling
\
[i
\
]/

nc:DocumentBinary/

nc:BinaryDescriptionText


3


Filing Document
Type


/
mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseFiling
\
[i
\
]/

nc:DocumentSubjectText


160




Filing Docket
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseFiling
\
[i
\
]/

nc:DocumentCategoryText


5


Element Namespace Const
raint


Property
Name


XPath


Namespace


Court
Location
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseCourt/

j:CourtDivisionText


CourtDivisionText.xls


Case Type


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
e
xt:Case/

nc:CaseCategoryText/text()


CaseCategoryText.xls


Case Level
Security


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseSecurityText


CaseSecurityText.xls


Filing Prior
or Persistent
Offender
Code


/mo
-
cdex:
MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

mo
-
cdex
-
ext:CasePriorOffenderText


CasePriorOffenderText.xls


Neighborhood
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

j:IncidentAugmentation/

j:IncidentArrest/

mo
-
cdex
-
ext:Booking/

j:BookingDetentionFacility/

nc:FacilityLocation/

nc:LocationLocale/

nc:LocaleNeighborhoodName


LocaleNeighborhoodName.xls


County
where
offense
occurred


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
\
[i
\
]/

mo
-
cdex
-
ext:
ChargeIncident/

nc:IncidentLocation/

nc:LocationAddress/

nc:StructuredAddress/

nc:LocationCountyName


LocationCountyName.xls


State where
offense
occurred


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge
\
[i
\
]/

mo
-
cdex
-
ext:ChargeIncident/

nc:
IncidentLocation/

nc:LocationAddress/

nc:StructuredAddress/

nc:LocationStateUSPostalServiceCode


LocationStateUSPostalServiceCode.xls


Prosecutor
Type


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

j:CaseAugmentation/

j:CaseProsecutionAttorn
ey/

j:CaseOfficialRoleText/text()


CaseOfficialRoleText.xls


Address
Type Code


/mo
-
cdex:MoCriminalDataExchange/

nc:Location
\
[i
\
]/

nc:LocationCategoryText


AddressLocationCategoryText.xls


Address

/mo
-
cdex:MoCriminalDataExchange/


LocationStateUSPostalServiceCode

State

nc:Loca
tion/

nc:LocationAddress
\
[i
\
]/

nc:StructuredAddress/

ncLocationStreet/

nc:LocationStateUSPostalServiceCode


Person Race


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person
\
[j
\
]/

nc:PersonRaceText


PersonRaceTex
t.xls


Person Sex


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

nc:PersonSexCode


PersonSexCode.xls


Person State
of Drivers
License Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Person/

mo
-
cdex
-
ext:PersonAugmentation/

nc:DriverLic
ense/

nc:DriverLicenseIdentification/

nc:IdentificationJurisdictionText


LocationStateUSPostalServiceCode


Person ID
Type


/mo
-
cdex:MoCriminalDataExchange/

/mo
-
cdex
-
ext:Person
\
[j
\
]/

nc:PersonOtherIdentification
\
[i
\
]/

nc:IdentificactionSourceText


IdentificactionSourceText.xls

Detection
Method

/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

mo
-
cdex
-
ext:ChargeIncident/

mo
-
cdex
-
ext:DrivingIncident/

mo
-
cdex
-
ext:

DrivingIncidentDetectionMethodText


DetectionMethodText.xls

Missouri
Charge Code




/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Charge/

j:ChargeSanction/nc:ActivityIdentifica
tion/

nc:IdentificationID


Listing Provided via existing MSHP
Site




Filing
Document
Format Type


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:
CaseFiling
\
[i
\
]/

nc:DocumentBinary/

nc:BinaryDescriptionText


BinaryDescriptionText.xls


Filing
Document
Title



/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseFiling
\
[i
\
]/

nc:DocumentSubjectText



Docket codes and document
descriptions
.xls


Filing Docket
Code


/mo
-
cdex:MoCriminalDataExchange/

mo
-
cdex
-
ext:Case/

nc:CaseFiling
\
[i
\
]/

nc:DocumentCategoryText



Docket codes and document
descriptions
.xls


Minimum Property Set to Satisfy a Filing

In order to accept a case, there are cert
ain data elements that must exist before the case may be
imported. These data elements are as follows: (
Defendant) First Name
, (
Defendant)

Last Name
,
Prosecutor Type
,
Prosecutor Bar Number
,
Prosecutor Case Number
,
JIS Filing Charge Code
,
Violation Numbe
r, Filer Charge Description, Violation Date, Violation Time
, (
Filed in) Court
Location Code.


Element and Property Constraints



Weight MeasureUnitText will always be pouind using the "LBS" code.



nc:DateTime element will follow the XML timestamp format of "Y
YYY
-
MM
-
DDTHH24:MI:SS.00000"
e.g "2011
-
06
-
05T13:32:00.00000"



Each s:id must be unique throughout the entire XML document.



Each s:ref used must refer to a valid s:id.



Each s:metadata must refer to a valid nc:Metadata s:id



Each nc:RoleOfPersonReference and nc
:RoleOfOrganizationReference s:ref must refer to an s:id of
a valid mo
-
cdex
-
ext:Person s:id or mo
-
cdex
-
ext:Organization s:id respectively.



Each j:Citation must be associated with a j:Offense

with the j:OffenseCitationAssociation



Speed nc:MeasureUnitText wi
ll alway be in miles per hour using the "MPH" code.



nc:Date elements will follow the standard XML Date formate "YYYY
-
MM
-
DD" e.g. "1967
-
08
-
13".



Each nc:CaseFiling may
be

none

to many nc:DocumentBinary but only on
nc:DocumentCategoryText.



Each nc:DocumentBin
ary must have a corresponding nc:

BinaryDescritionText and

a
corresponding nc
:
DocumentSubjectText

or there can be no nc:DocumentSubjectText at all. A
ll

related

will occupy the same position with in their respective arrays, i.e.

the first
nc:DocumentBinary
will be a document of the first nc:BinaryDescription and will be named using
the first nc:DocumentSubjectText. If no nc:DocumentSubjectText is provided the JIS description
of the Docket code matching the nc:DocumentCategoryText will be used.
Conceptual Da
ta Model