[1]
The Code element is the intended root element of the schema. The Code element contains information about a specific code in a code table. Many courts use a string value plus a numeric or alphanumeric code value to represent one piece of information. As a result, the Code element includes both Code:Name and Code:Value elements as children elements. The Code element also includes a Code:Alias element so other values can be mapped to Code:Name values. Finally, the Code element includes a Code:GenericType element so generic type values can be mapped to more specific Code:Name values. [2] The following table illustrates a simple code table and four code values. Assume the code table below has a CodeTable:Name value equal to Document Type. Name | Value | Alias | Generic Type |
---|
MOTION FOR SUMMARY JUDGMENT | 0001 | Motion: Summary Judgment | Motion | MOTION FOR A NEW TRIAL | 0002 | Motion: New Trial | Motion | MOTION FOR A DIRECTED VERDICT | 0003 | Motion: Directed Verdict | Motion | MOTION FOR FEE WAIVER | 0004 | Motion: Fee Waiver | Fee Waiver |
[3] Notice in the example above that code 0004 has a generic type equal to Fee Waiver, which is different than the generic types for the other motions. This is an illustration of how a generic type can be used to trigger special processing. See the Document:GenericType element in Filing XML for more information. [4] See also the CodeTable schema. [5] Code:Name is a human-readable name associated with the code value taken from a case management system code table. There must be a one-to-one relationship between the values in Code:Name and Code:Value. [6] Code:Value is a numeric or alphanumeric code value taken from a case management system code table. There must be a one-to-one relationship between the values in Code:Name and Code:Value. [7] Code:Alias is an alias for a Code:Name value. The Code:Alias can be used to (a) provide a more user friendly code name or (b) to map a Code:Name value or Code:Value value to a standard set of codes harmonized and used in one jurisdiction for many courts. For example, Court A might use Motion: Summary Judgment as a Code:Name value, while Court B might use Motion for Summary Judgment as a Code:Name value. If the State standardizes on the string Motion: Summary Judgment, Court B can use the Code:Alias element to map its Code:Name value to the State's standard code name. If values for both Code:Name and Code:Alias are present, then applications should present users with Code:Alias rather than Code:Name. [8] Code:GenericType is a generic value for one or more values expressed in Code:Name elements. The Code:GenericType element can be used to map general values to more specific values. For example, a court might have the following document types: (a) Motion for Summary Judgment, (b) Motion for a New Hearing, and (c) Motion for Attorney Fees and Costs. Each of these values would be listed in a Code:Name element. The corresponding Code:GenericType for each of the values above might be Motion. This allows applications to develop rules and workflow for a Motion, instead of having to consider each individual document type. Child Element(s) | minOccurs | maxOccurs | Filter | 1 | unbounded |
[9] Code:Filters is a container element for the Code:Filter element. See Code:Filter element for more information. [10] Code:Include provides a simple filter mechanism. The Code:Include element provides a Yes or No value for each Code:Value, Code:Name, and Code:Alias combination. This allows either a court or a service provider to decide whether to include or not include a code for use in an application.
[11] The Code:Include element functions based on the assumption that the following is allowed (a) a court publishes Policy XML in a Policy Repository with code values in it, and (b) an application is allowed to download the Policy XML locally, alter the policy, and create one or more derivative policies for its own internal uses. This means that while there is always one officially published Policy XML file maintained by the court or by a policy authority, local court policies can be manipulated for specific applications. [12] For example, assume a Policy XML has 100 Filer Types in it. However, the Policy XML, in a particular installation, only requires one of the Filer Types (for example, the value Sheriff/Law Enforcement). In this situation, the sheriff, a filer, does not need to see all of the possible Filer Types. The sheriff only needs the Sheriff/Law Enforcement Filer Type. In this situation, in the local Policy XML used by the sheriff, the Code:Include value for Sheriff/Law Enforcement could be set to Yes and all other values could be set to No. The application would be required, in this case, to show only the code values matching Code:Include elements with Yes values. This provides a simple means of filtering values and also ensures that the filer will not select the wrong value. [13] The selection of values in one code may create dependencies that limit the logical use of values in another table. Although representing such dependencies could be done with a longer court key, it would make the court key very long. Further, the court key would no longer represent a physical/logical division of the court, but rather a case type (or something else) of a division within a court. This is undesirable. CodeTable:Filter, therefore, is used to filter tables based on values in other tables. [14] Based on the assumptions that code dependencies (a) are complex, varied, and specific to an implementation and (b) do not always occur, the Policy XML filter mechanism uses simple, generic Code:Filter elements. Each code table or code may have one or more Code:Filter elements. Each Code:Filter element includes a Code:FilterName element and Code:FilterValue element. Either the court or a service provider may create its own filters by manipulating a local Policy XML file. The name/value pair may be any name and value. See CodeTable:Filter for an example. |