Justice Partner Outreach
Glossary
Some or all of the following terms and acronyms are used on this website.
| Abstract | An XML element or schema type may be declared abstract, meaning that it may not be used directly. An abstract element may not be directly used in an instance but must have a non-abstract element in its substitution group. Example: an abstract element 'Address,' which defines the contents of an address). A non-abstract 'HomeAddress' element that is substitutable for “Address“ can be used as an XML element. The “HomeAddress” structure reuses the previously defined “Address” contents, but the tag provides a specific context. Schema types also may be declared abstract. Similar to abstract elements, abstract types may not be directly used to reference elements but must have a non-abstract type that extends/restricts it. The non-abstract type can then be used to reference XML elements. The concept of abstractness is taken from object-oriented programming, where an abstract class may be defined, requiring sub-typing before instantiation |
| adapters | An adapter is a set of computer codes for an application or system that lets it communicate with another application or system, or typically with middleware or an ESB to consume or supply data coming/going to another application connected to the hub. For large backend COTS enterprise resource planning systems (finance, HR/payroll, etc.) the adapter is provided with the system. For most other systems, this must be custom developed. For newer systems and contemporary technologies, adapters can be relatively easy to create and implement and will often include messaging and Web services. For older applications and older technologies, creation of an adapter can be difficult and more expensive. |
| AOC | Refer to 'Judicial Council' |
| application programming interface (API) | An interface that enables programs to communicate with each other. |
| architecture | Those characteristics of a network, operating system, application program, or enterprise that facilitate the interchange of information. |
| attribute | Data model descriptor/category for a piece of information that characterizes an entity or a relationship. |
| authentication | The process whereby a user or information source proves its identity and verifies that a user is who they purport to be. The process of identifying an individual usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who they claim to be but says nothing about the access rights of the individual. Any method used to assure that the alleged source of the received data is the actual source and that the message received is the same as the one sent in every respect. |
| case identifiers | The alphabetic and/or numeric characters assigned to identify a particular case. |
| CCTC | California Courts Technology Center |
| CCMS | California Court Case Management System |
| CCMS data exchange | The sharing of data among systems in order to satisfy a particular business need (i.e., file a case, update status on a warrant, etc.) All data exchanges are assigned a unique name, which contains a three-digit number starting with “8” or “9.” Exchanges beginning with “8” are requests made from a partner system to CCMS. Exchanges beginning with “9” are requests made from CCMS to a partner system. See information exchange package documentation (IEPD). |
| CCMS data exchange specification | CCMS data exchange specification packages (also referred to as “DX zip package” or “DX package”) standardize the data content of each exchange. A data exchange specification is a .ZIP file that contains the following artifacts:
|
| CMS | Case management system |
| common element block (CEB) | Standardized data components that are common across multiple CCMS data exchanges. CEBs are represented as XML schemas and allow for consistency among exchanges rather than uniquely redefining similar components for each exchange. |
| common ISB header XML schema | XML schemas that define exchange header information required for proper transport of messages. |
| data component | A fundamental building block of NIEM. Data components are the basic business data elements that represent real-world objects and concepts. Information exchanged between agencies can be broken into individual components, for example, information about people, places, material things, and events. Components that are frequently and uniformly used in practice are specified in NIEM and can then be reused by practitioners for information exchanges, regardless of the nature of their business or the operational context of their exchanges, provided they are semantically consistent. |
| data dictionary | A set of data elements and their definitions, including any metadata and representations associated with them |
| data element | The fundamental data structure in a data processing system. Any unit of data defined for processing is a data element; for example, ACCOUNT NUMBER, NAME, ADDRESS, and CITY. A data element is defined by size (in characters) and type (alphanumeric, numeric only, true/false, date, etc.). A specific set of values or range of values may also be part of the definition. |
| data encryption | Methods used to encode computerized information. |
| data integrity | The assurance that data is an accurate and complete representation of the data as created or modified by its originator and that computerized information resources remain configured as intended by the person responsible for them. |
| data level integration | A form of enterprise integration application that integrates different data stores to allow information sharing among applications. It requires loading data directly into the database using its native interface and does not involve the changing of business logic. |
| data model | A representation of the information required to support a particular business function or set of functions. As analysis is being done for the business requirements of a system, the information requirements are also identified and captured in a data model. |
| data warehouse | An information-sharing technique that relies on a separate database created by transforming data from several sources into a single database, along with application programs to retrieve the transformed data. |
| EFSP | Electronic Filing Service Provider |
| enterprise architecture | The computer, network, and software architecture for an entire organization. The enterprise architecture sets the standard for all connected devices, protocol, data, and software. |
| event/business event | The institutional or subject action that triggers an exchange, for example, arrest, issuance of warrant, sentencing, correctional and discharge, etc. |
| exchange trigger | An event within a process at which information sharing does, or should, occur; information that is useful to another agency may be collected, or information from another agency may be required, or both. |
| exchange mapping | The process of mapping an exchange model to NIEM in order to ensure semantic compatibility prior to information exchange. An exchange model represents local data. |
| exchange package | A description of specific data exchanged between a sender and a recipient. The exchange package is usually coupled with additional documentation, sample XML instances, and business rules, etc. to compose an IEPD. |
| exchange specification | Any details describing an exchange, including schemas and business rules, etc. This term often describes the content of an IEP. |
|
eXtensible Markup Language (XML) |
A structured, extensible language for describing information that is being sent electronically from one entity to another. XML schema is the preferred standard to define the rules and constraints for the characteristics of the data, such as structure, relationships, allowable values, and data types. |
| extension schema | An XML schema that defines the data elements to be used in an exchange, but which do not exist in the NIEM model and, therefore, must be extended. |
| formatting data | Metadata that expresses the appearance of data on a page or screen. XSL and CSS style sheets contain formatting data. |
| function | A capability of an application program, for example case initiation, meeting notification, decision outcome recording, etc. |
| functional specification | A formal description of a software system that is used as a blueprint for implementation. Specifications should state the purpose of the program, provide implementation details, and describe the specific functions of the software from the user's perspective. |
| Global Justice XML Data Model (GJXDM) | A data model and dictionary sponsored by the US Department of Justice and governed by the Global Justice Information Sharing Initiative. The GJXDM and its related processes are the basis on which NIEM was built in partnership with US Department of Homeland Security. |
| IEP | See information exchange package (IEP). |
| information exchange package (IEP) | A description of specific information exchanged between a sender and a recipient. IEPs are usually coupled with additional documentation, sample XML instances, and business rules, etc. to compose an IEPD. An IEP may be referred to as an “exchange package.” |
| IEPD | See information exchange package documentation (IEPD). |
| information exchange package documentation (IEPD) | The aggregation of IEP information to form a complete set of documentation that completely describes an information exchange. This may include additional documentation, business rules, and sample instance data, etc. |
| Integrated Services Backbone (ISB) | A combination of tools and services that allow courts to securely transmit and receive case-related information critical to public safety and welfare. The ISB is used to provide standardized interfaces based on data exchange standards across all justice partners and service providers, minimizing the need for custom solutions for each court. |
| interface | 1. A program or device that connects different programs or devices. 2. The process by which a software application interacts with other software or users. In object-oriented programming, an "object's" interface is often described separately from the internal logic in a process known as "encapsulation." The interface encapsulates and hides the internal logic, allowing one to change and improve object code without affecting other objects. An interface description is made public so other objects/applications know how to interact. Software is said to implement an interface if it conforms to the behavior as defined in an interface description. The Object Management Group (OMG) has defined a formal syntax for defining interfaces in a programming language-neutral fashion. This is called the “OMG Interface Description Language” (OMG IDL). |
| ISB | See Integrated Services Backbone (ISB). |
| IP | integration partner |
| JP | justice partner |
| JMS/IMS | jail management system/inmate management system |
| Judicial Council (Staff) | The Judicial Council is the policymaking body of the California Courts. Its staff is formerly known as the 'Administrative Office of the Courts'. |
| legacy application | Legacy applications are those that have been inherited from languages, platforms, and techniques earlier than current technology. |
| legacy data | Information stored in an old or obsolete format or computer system that is, therefore, difficult to access or process. |
| legacy system | Older software and hardware systems still in use and generally proprietary. An older computer system such as a mainframe or minicomputer. It may also refer to only the software. |
| LegalXML | LegalXML produces standards for electronic court filing, court documents, legal citations, transcripts, criminal justice intelligence systems, etc. |
| metadata | Data about data. There are at least three types of metadata of interest: semantic data, which gives the meaning of the raw data; formatting data, which describes the appearance of the data on screen or on the page; and, intellectual property data, which describes data ownership conditions. Metadata describes how and when and by whom a particular set of data was collected and how the data is formatted. Metadata is essential for understanding information stored in data warehouses. Example: for the data "3000N," the metadata might be "latitude." Markup languages such as SGML and XML encapsulate data with tags that contain text describing the metadata. |
| National Information Exchange Model (NIEM) | An XML-based information exchange framework from the United States. NIEM represents a collaborative partnership of agencies and organizations across all levels of government (federal, state, tribal, and local) and with private industry. The purpose of this partnership is to effectively and efficiently share critical information at key decision points throughout the whole of the justice, public safety, emergency and disaster management, intelligence, and homeland security enterprise. NIEM is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that will enable jurisdictions to automate information sharing. |
| object | A term used frequently in relation to XML and computer science. Strictly speaking, an object is a runtime software construct that resides in the random access memory (RAM) of the host computer. Objects are created by applications from code that defines the object's behavior; this code is called a “class.” In object-oriented programs, objects interact with other objects to create the behavior of the application. An object's behavior is described by an interface consisting of methods and properties. A method can be thought of as a behavior of the object that can be triggered by calling it and optionally passing parameters. |
| publish/subscribe | An information-sharing modality in which the subscriber user indicates a desire to be informed if certain events occur affecting a certain person, incident, or case, and the publisher system agrees to provide the information. |
| pull | To move data from one system’s domain to another system’s domain. The system that extracted the data is now accountable for the data pulled into its system. Once the pull occurs, the source system is no longer accountable for the data it sent. |
| push | The system that received the data is now accountable for the data pushed to it. Once the push occurs, the sending system is no longer accountable for the data it sent. |
| query | A request for information. A query allows flexibility in both the information being requested and the timing of the information request. |
| query/respond | An information-sharing modality in which the user of an application requests specified information from another information system. |
| RMS | Records management system |
| relationship | The association between two entities in a data model. |
| rendering XMl | XML is not easily usable to readers in its native format and should be transformed for presentation either by a CSS, XSLT (to well-formed HTML) for browser viewing, or by XSL-FO into a format for viewing by other presentation applications (e.g., into Adobe Acrobat PDF or Microsoft Word .doc files). |
| response schema | Defines the “response” payload of a data exchange |
| request schema | Defines the “request” payload of a data exchange |
| request-reply asynchronous | Each data exchange consists of a “request” message and a “response” message. For data exchanges that are request-reply asynchronous, the request and response are handled in the same line of communication. The requesting system waits for a response and continues waiting until it receives a response. |
| request-reply synchronous | Each data exchange consists of a “request” message and a “response” message. For data exchanges that are request-reply synchronous, the request and response are handled in separate lines of communication. The requesting system sends a request and does not wait for a response. If a response is required, the responding system opens a new line of communication and sends a new “request” message. |
| sample XML instance | An XML file that contains a sample instance for each “request” and “response” message that is part of a data exchange. Sample instances validate against “input” and “output” schemas. |
| schema | See XML schema. |
| service description documents (SDDs) |
Supplemental documents that provide business and technical stakeholders with details regarding the context and business rules for a data exchange. SDDs include detailed descriptions that include the involved partners, objectives, related exchanges and forms. Also included are primary and error handling information flows, triggering and subsequent events, business rules, and allowable values. Service description documents are based on the Global Justice Reference Architecture’s Service Specifications Guidelines. |
| Simple Object Access Protocol (SOAP) | A protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services protocol stack, providing a basic messaging framework on which abstract layers can be built. |
| SME | Subject matter expert |
| SOAP | See Simple Object Access Protocol (SOAP). |
| standards organizations | Organizations that have defined procedures for the determination that a standard is necessary, the creation of a standard, and the periodic review of a standard. ANSI, IEFT, ISO, NIEM, and WWWC (W3C) are examples of standards organizations. |
| structured data | Data that carries with it the associated semantic data or a pointer to the semantic data. |
| transaction data | The descriptors or attributes of a single activity. Example: the court disposition transaction data includes the court name, data, case, charges, decision, and sentences. |
| Username (username, user id, user ID) | A name used to gain access to a computer system. Usernames and passwords are required in multiuser systems. In most such systems, users can choose their own usernames and passwords. |
| validation | Evaluating a system during or at development completion to determine if it satisfies all requirements |
| valid XML | An XML instance (document) whose structure has been verified in conformance to a DTD or schema by a validating parser. Note that an XML instance must be well-formed to be valid, but it does not need to be valid to be well-formed. This is because a parser will always check well-formedness constraints but will only check validation constraints if it is a validating parser. |
| WSDL |
Web Service Description Language. A WSDL is an explicit description of the Web services interface for each exchange. WSDL content is defined by the NIEM schemas. The exchange specifications contain two types of WSDLs:
|
| XML | See eXtensible Markup Language (XML).
|
| XML API | In the context of XML, parsers expose their data to a calling application using an interface. An interface is a specification, which the parser conforms to, that describes how the parser will pass data from an XML document to a calling application. |
| XML attributes | In the context of XML, attributes provide a mechanism for attaching additional metadata to an XML element. Example: <element attribute="value"/>. An XML attribute is not equivalent to an object or relational model attribute. Data model entity attributes may be expressed as either XML attributes or elements. Frequently in discussions surrounding the application of XML to data models, one party will be referring to attributes in the context of XML and another to attributes in the context of data models, causing confusion. |
| XML child element | The hierarchical nature of XML allows elements to contain or be nested inside other elements, forming a conceptual data tree. Often XML elements are referenced in terms of parent-child relationships. A child element is one contained between the tags of a parent element. Child elements are also referred to as “descendants”, while parent elements may be referred to as “ancestors.” |
| XML comments | The structure for inserting free text comments into XML. The same structure is used for HTML comments. Example: <--comment text here-->. |
| XML component | A generic term used to refer to XML elements, attributes, and XML schema-type definitions. |
| XML declaration | Every well-formed XML document must begin with a statement that as a minimum declares the version of XML to which the document conforms. Example: <?xml version="1.0">. |
| XML document | A data object is an XML document if it is well-formed, as defined in the XML 1.0 specification. A well-formed XML document may in addition be valid if it meets certain constraints as described by a schema. Synonymous with XML instance. |
| XML document tree | The logical model of an XML document conceptualized as a data tree, with a root node and branch nodes ending at data that can be thought of as the leaves. Every XML document must contain a single root node. |
| XML elements | The fundamental unit of information in XML. Elements are encapsulated by tags and may contain, among other things, attributes (declared inside the opening tag), other elements, or data. |
| XML grammar/vocabulary | Related terms often used synonymously to indicate a set of element and attribute names and the structures described by a schema or set of related schemas that employ the elements and attributes. More precisely, the term "vocabulary" implies a commonly defined set of elements and attributes, while "grammar" refers to the composition of the vocabulary into meaningful business documents by one or more related schemas. An XML namespace may be used to describe a vocabulary, while a schema may employ vocabulary from a single or multiple XML namespaces. |
| XML instance | An instance of XML that contains data whose format and inclusion is controlled by the associated XML schema. |
| XML namespace | An XML namespace is a conceptual space to which element and attribute names may be assigned. An XML namespace is declared within an XML instance by assigning a uniform resource identifier (URI) reference and an optional qualification prefix to an element. The element and all its children are considered to be in the XML namespace unless specifically qualified with another namespace's prefix. The URI reference does not have to an associated document physically at the URI. Within an XML schema, the "targetNamespace" attribute may be used to indicate that all elements declared within the schema are to be treated as in the target namespace. |
| XML name token | Any mixture of name characters where a name character obeys the XML name convention. An XML name is a token beginning with a letter or a punctuation character and continuing with letters, digits, hyphens, underscores, colons, or full stops, together known as “name characters.” |
| XML parser |
A software application that either reads or receives a text-encoded binary stream, decodes it, verifies the input conforms to well-formedness constraints, checks validity of the XML instance against a schema if available, and exposes the content using an API to a calling application. A parser can be a standalone application, but is most often a module called by a larger program (the calling application). A parser also may be referred to as an “XML processor.” |
| XML processor | A synonym for an XML parser. |
| XML root element | Refers to the XML element in which all other elements must be nested. The root element (a physical XML construct) is a child of the logical root node of a document tree. |
| XML root node | The first node originating the XML document tree. The root node is not the same as the root element. |
| XML schema annotation |
The XML schema language allows addition of annotations to schema components through an annotation element (<xsd:annotation>) which must contain either a documentation element (<xsd:documentation>) or AppInfo element (<xsd:appinfo>). A source attribute may be added to either element to provide a URL reference to the source of the annotation. Annotations are a more sophisticated way to provide documentation and application information that may be parsed and accessed by applications using an API. |
| XML schema | Defines the vocabulary (elements and attributes), the content model (structure, element nesting, and text content), and data types (value constraints) of a class of XML documents. |
| XML schema type | An XML component defined by the XML schema language. Types do not show up in XML instances; they are used within the schema to express relationships and through type inheritance, add an object-like capability to XML schemas. Types may be simple, that is, they allow definition of simple data-type constraints on element values; or they may be complex, that is, they define structures consisting of other elements. |
| XML tags | XML (and its parent SGML) annotate metadata through the use of tags that indicate which text in a document is considered metadata and which is considered data. Tags are surrounded by markup characters. As an example, the data "3000N" can be marked up in XML, <latitude>3000N</latitude>. The tags are<latitude>(start tag) and</latitude>(end tag).
|
| zero latency | No delay between an event and its response. |
| zero latency process | An automated process with no time delays (i.e., no manual reentry of data) at the interfaces of different information systems. |