Attribute(s) | type | use | fixed/default | Alphabetize | YesNo | optional | None | Use | Uses | optional | None | CodifiedName | CodifiedNames | required | None |
Introduction[1]
The CodeTable element is the intended root element of the schema. A CodeTable element and its children elements contain values for court case management system code tables. For example, court code tables might include case categories or document types. [2] The following definitions are used in this documentation and are meant to represent the hierarchy of a court structure: (a) Country, (b) State, (c) County, (d) Court, (e) Location, (f) Division, (g) Subdivision, and (h) Group. The term division with a small d is meant to generically refer to any of the structural names listed above. [3] A single Court Policy is able to represent code tables for either (a) one division of one court or (b) several divisions of one court. A single Court Policy does not represent code tables for more than one court. [4] Different courts often have different names for the same or similar types of code tables. Policy XML allows a court to preserve its customary code table name, while providing a facility that allows service providers to map like-code-tables-to-like-code-tables. [5] Some courts use either numeric or alphanumeric code values along with human-readable code values. Policy XML supports mapping human-readable code values to numeric or alphanumeric code values. Court Keys[6] Cases are initiated in a division of a court and are often categorized as case types based on the court division. The applicability of a code table is sometimes dependent on the case type. As a result, Policy XML is able to express code table associations at the lowest level division. Policy XML makes such associations using court key values. [7] For example, if a division of a court is Civil, then a code table named Case Category might have a court key (such as, USCASacramentoSuperiorCivil) associated with the following code table values: (a) Auto Tort, (b) Other PI/PD/WD, (c) Other Tort, (d) Employment, (e) Contract, (f) Real Property, (g) Unlawful Detainer, (h) Judicial Review, (i) Complex Litigation, (j) Enforcement of Judgment, (k) Other Civil, and (l) Small Claims Appeals. [8] A criminal court would have a different court key (such as, USCASacramentoSuperiorCriminal) and a different set of values for a case category table. Since each court key is unique to a division of a court, when a court key is associated with a code table, it is possible to programmatically associate the code table values with a division of court (i.e., civil case categories are associated with civil court; criminal case categories are associated with criminal court). Generic Types[9] Policy XML supports Generic Types. Generic Types are general, vendor (or California AOC) approved and agreed code names and table names that allow applications to map like-code-tables-to-like-code-tables or like-codes-to-like-codes, even though different courts call the same value by a different name. [10] For example, assume the following values in Court 1, Court 2, Court 3, and Court 4: [11] Court 1, Party Type = DEF. [12] Court 2, Party Type = Defendant. [13] Court 3, Party Type = defendant. [14] Court 4, Party Type = Child. [15] In this example, while these values may be important to each court, a filing application wants to know, in an automated way, a unique value for each of these meanings so that software can be written and workflow can proceed in the same way for different courts. [16] In the example above, the Court Policy solution is to create a limited number of Generic Party Types. For example: [17] Court 1, Party Type = DEF, Generic Party Type = Defendant. [18] Court 2. Party Type = Defendant, Generic Party Type = Defendant. [19] Court 3, Party Type = defendant, Generic Party Type = Defendant. [20] Court 4, Party Type = Child, Generic Party Type = Defendant [21] Examples of Generic Party Types might include: Plaintiff, Defendant, Attorney, or Judge. [22] There can be Generic Types for both code tables and for codes. The goal in defining any category of Generic Type values should be to define five to twenty distinct, agreed, generalized values that map to more specific values in court code tables. It is impossible to define all Generic Types to fit all situations; however, even a minimal number of agreed Generic Types will facilitate communication and interoperability among software applications. Code Table Dependencies[23] Some code table values are dependent on other code table values at a higher level. For example, values that populate a case category list might depend on a prior selection from a list of case types. If the case type is unlawful detainer, then only case categories related to unlawful detainer are relevant in a dependent list. Policy XML is able, therefore, to express code table dependencies between higher level code tables and lower level code tables using filters. Representing such dependencies or creating new dependencies is optional in Policy XML. See CodeTable:Filter element for more information. Alphabetize and Use Attributes[24]
The CodeTable element has an Alphabetize attribute. The Alphabetize attribute is used to suggest to an application whether to alphabetize a code table list when presenting it to users or whether to keep the values in document order. The attribute is only a suggestion. An application may ignore the Alphabetize attribute. [25]
The CodeTable element has a Use attribute. The Use attribute tells an application whether the code table is (a) Required, (b) Optional, (c) Depreciated, or (d) Private. Depreciated means that a code table value is acceptable but not the preferred value. For example, if there were two values with the same meaning, such as PLF and Plaintiff, PLF might be depreciated, while Plaintiff would be the preferred term. A Private table would be a table that is in Policy XML for use by the court or by a vendor, but which is not intended to be displayed to end users. Codified Names[26] The attribute CodifiedName allows policy developers to use standard names. This attribute takes a number of enumerated values. A value Other is included for names that do not match any codified name. Child Element(s) | minOccurs | maxOccurs | Code | 1 | unbounded |
[27] CodeTable:Codes is a container element for one or more CodeTable:Code elements. [28] 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 |
[29] 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. [30] See also the Code schema. [31] CodeTable:Name is the exact string value of the code table name in the court case management system. This string is used to match the Policy XML's CodeTable:Name value with the case management system code table name. [32] CodeTable:Alias is an optional element that can be used to map the court case management system code table name (e.g., CodeTable:Name value) to either (a) a human readable name or (b) to a standard table name adopted for multiple case management systems in the jurisdiction. Use of CodeTable:Alias in situation (b) is recommended for harmonizing code table names on a state or federal level. Child Element(s) | minOccurs | maxOccurs | CourtKey | 1 | unbounded |
[33] CodeTable:CourtKeys is a container element for one or more CodeTable:CourtKey elements. [34] CodeTable:CourtKey is a value for a court key for the court or a court division listed in the Policy XML. For example, if a court is divided into criminal and civil divisions, then the Policy XML for the court will have two court keys, one for each division of the court. By associating a court key value with a code table, the CodeTable:CourtKey element can be used to distinguish code tables used for each division of the court. [35] If there are two code tables that are exactly the same (such as a code table for Salutations), then the code table can be associated with more than one court key corresponding to the court divisions in which the code table is used. [36] The Policy:CourtDetails and CourtDivision:CourtDetails elements in Policy XML includes each division's CourtDetails:CourtKey. See the CourtDetails schema. Child Element(s) | minOccurs | maxOccurs | Mapping | 1 | unbounded |
[37] CodeTable:Mappings is a container element for one or more CodeTable:Mapping elements . See CodeTable:Mapping element for more information.
Attribute(s) | type | use | fixed/default | CodeType | CodeTypes | required | None |
[38] CodeTable:Mapping is used to map code tables to XML specifications. For example, if a code table value is Case Categories, then information in the CodeTable:Mapping element can be used to map the CaseCategory element in Legal XML Court Filing 1.0 to the list of values in the code table. In the same way, the CodeTable:Mapping element can be used to map to the Case:CaseCategory element in 2GEFS Filing XML. [39] CodeTable:Mapping has an attribute CodeType that can have two values (a) CodeName and (b) CodeGenericType. CodeName means the mapping is to the Code:Name element, while CodeGenericType means the mapping is to Code:GenericType element. Child Element(s) | minOccurs | maxOccurs | Filter | 1 | unbounded |
[40]
The CodeTable:Filters element is a container element for one or more Filter elements. See Filter element for more information. [41] CodeTable:Specification is a unique name of the specification to which a code table is intended to be mapped. [42] CodeTable:ElementName is the name of the element or attribute, including the namespace prefix if it exists, in the specification being mapped. [43] CodeTable:XPathLocation is a valid XPath string that points to the element or attribute in the specification being mapped. [44] Some code table values are dependent on other code table values at a higher level. For example, values that populate a case category list might depend on a prior selection from a list of case types. If the case type is unlawful detainer, then only case categories related to unlawful detainer are relevant in a dependent list. Policy XML is able, therefore, to express code table dependencies between higher level code tables and lower level code tables using filters. Representing such dependencies or creating new dependencies is optional in Policy XML. [45] 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. [46] Based on the assumptions that such dependencies (a) are complex, varied, and specific to an implementation and (b) do not always occur, Policy XML represents dependencies using generic CodeTable:Filters and CodeTable:Filter elements. These elements operate as described in the following paragraphs. [47] Each code table or code has one or more CodeTable:Filters/CodeTable:Filter elements. Each CodeTable:Filter element has a name and a value. Either the court can publish filters or a service provider can create its own filters by manipulating a local version of Policy XML. The name/value pair can be any name and value. [48] Assume the following: [49] (a) Court Key = USCASacramentoJuvenile (applies to both tables). [50] (1) Code Table = Filing Type, (1.1) Code Name = Complaint, (1.2) Code Name = Transfer. [51] (2) Code Table = Case Category, (2.1) Code Name = Delinquent, (2.2) Code Name = Unruly, (2.3) Code Name = Traffic, (2.4) Code Name = Adoption. [52] In this example, Delinquent, Unruly, and Traffic are always based on Complaints. Adoptions can be either Complaints (to the Juvenile Court) or Transfers (from Superior Court). [53] By adding the following filters, dependencies are represented: [54] Code Name = Delinquent, Filter: Name = Filing Type, Value = Complaint. [55] Code Name = Unruly, Filter: Name = Filing Type, Value = Complaint. [56] Code Name = Traffic, Filter: Name = Filing Type, Value = Complaint. [57] Code Name = Adoption, Filter: Name = Filing Type, Value = Complaint, Filter: Name = Filing Type, Value = Transfer. [58] If Complaint were selected as the Filing Type, then all four case categories would apply. However, if Transfer were selected as the Filing Type, then only the Adoption case category would apply. [59] An application using Policy XML may decide to use or ignore the Filters as it sees fit. [60] It may not be possible to achieve all code table dependencies using this generic Policy XML filter technique. Some configuration and value added services should be provided by service providers. [61] CodeTable:Code is an individual code in a code table. See the Code schema. |