Introduction[1] This document is the California Second Generation Electronic Filing Specifications (2GEFS) Court Filing 2.0 Specification (Filing XML). The web-based version is broken into several web pages, one for each schema. The Adobe PDF version is one PDF document for all schema unique to Filing XML and an additional PDF document that includes documentation for Building Block schema. Building Block schema are common to Filing XML, Confirmation XML, Notice XML, and Policy XML. Both the web-based format and the PDF format contain links to all schema documentation and the schema themselves. An accompanying document, 2GEFS Concepts, augments this specification with a high-level overview of terminology, models, relationship among specifications, and related concepts. [2] Please go to the following links to find these and other resources: [3] California AOC EFiling Standards Website: http://www.courtinfo.ca.gov/programs/efiling/standards.htm#2gefs. [4] California AOC Terms of Use: http://www.courtinfo.ca.gov/programs/efiling/termsofuse.htm. [5] Filing Specification: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/. Filing XML[6] Filing XML includes requisite elements to capture information necessary to (a) initiate a case in a target Case Management System ("CMS"), if a case does not exist, (b) file one or more documents into a case, (c) send name, contact details, identifiers and descriptions, and roles for people, organizations, and things associated with the case, (d) send charges or offenses in a case, (e) send and confirm service of process information (f) send and confirm payment information and (g) send and confirm calendar requests and schedules. Confirmation XML[7] Confirmation XML includes requisite elements to send confirmations of Filing XML and Notice XML. Confirmations include synchronous confirmations, asynchronous confirmations, and confirmation acknowledgements. [8] The general rule when responding with Confirmation XML is that any data accepted, changed, or added into the receiving system from the Filing XML or the Notice XML must be mirrored back in the Confirmation XML. The Confirmation XML must not include additional data that is unrelated to the Filing XML or the Notice XML. [9] Although the Confirmation schema is located in a Filing schema subdirectory, the Confirmation schema stands on its own and is not part of the Filing schema. Notice XML[10] Notice XML includes requisite elements to send court initiated transmissions and firm-to-firm transmissions. Court initiated transmissions are communications to parties that originate from the court without an associated filing. Firm-to-firm transmissions are communications to parties that originate from a law firm, but that are not sent to the court. This specification refers to these types of transmissions collectively as notices. [11] Although the Notice schema is located in a Filing schema subdirectory, the Notice schema stands on its own and is not part of the Filing schema. [12] Notice XML includes an ancillary specification named Notice List XML that is not part of the Filing XML specification. Envelope XML and Header XML[13]
The Filing XML specification includes an XML transmission envelope (Envelope XML) and envelope header information (Header XML). Envelope XML may be substituted with, or contained within, a SOAP envelope. Both Envelope XML and a SOAP envelope can contain Filing XML, Confirmation XML, or Notice XML. SOAP can also contain Envelope XML. There are, therefore, three similar means of enveloping and transporting filings, confirmations, and notices. Header XML, however, must be used regardless of the envelope technology used. [14] Although the Envelope schema and the Header schema are located in a Filing schema subdirectory, the Envelope schema and the Header schema stand on their own and are not part of the Filing schema. The Envelope schema is the root of all schemas. It imports the Filing schema, the Confirmation schema, the Notice schema, and the Header schema. [15] See the Envelope schema and the Header schema for more information. Envelope and Transmission Protocols[16] It is logically possible to transmit Filing XML, Confirmation XML, and Notice XML by HTTP, HTTPS, SOAP over HTTP (herein SOAP), SOAP over HTTPS (herein SOAPS), FTP, SMTP, Facsimile, postal mail, and bar coded paper (fax or post). The recommended approach is to use HTTP, HTTPS, SOAP and/or SOAPS as the transmission protocol for electronic filings and notices. Confirmations should be sent via HTTP, HTTPS, SOAP, SOAPS, or SMTP based on the scenarios described in this documentation and in the 2GEFS Concepts document. SMTP transmissions may include an XML attachment in the notification or message in the email body. Defining Applications[17] This specification describes four applications in its examples: [18] Sending Application: The sending application (also called filing application) is the application that initiates a transaction by sending Filing XML or Notice XML. The sending application may also be a receiving application if it receives confirmations or responses, but, because it first sends and then receives, it is named the sending application. [19] Receiving Application: The receiving application is the application that receives Filing XML or Notice XML and sends back Confirmation XML. The receiving application is also a sending application when it sends a confirmation or a response, but, because it first receives and then sends, it is named the receiving application. [20] Intermediary Application: An intermediary application is an optional application that passes through transactions and may do additional processing. An intermediary application is both a sending application and a receiving application, but it is never the first sending application and it is never the final receiving application. [21] ReplyTo Application: The ReplyTo application is an application that receives Confirmation XML from a receiving application. The ReplyTo application may or may not be the original sending application. The ReplyTo application may respond to an asynchronous confirmation with a confirmation acknowledgement. Initial and Subsequent Filings[22] Filing XML can be used for initial filings and subsequent filings. In the context of a filing, initial means a filing that initiates a new case and generates a new case number while subsequent means a filing with an existing case number.
Synchronous and Asynchronous Confirmations[23] Confirmation XML can be used for synchronous confirmations and asynchronous confirmations. A synchronous confirmation is a response that is sent as an immediate acknowledgment of receipt of a well-formed, valid XML filing. If HTTP (or a variation thereof) is used for transmission, then a synchronous confirmation must occur using the same unbroken HTTP connection used by the sending application. An asynchronous confirmation is a response sent later in the court filing workflow (e.g., a confirmation sent as acceptance or rejection of a filing). An asynchronous confirmation is usually initiated by a court clerk. There may be more than one asynchronous confirmations for one filing transaction. An asynchronous confirmation may occur several minutes, hours, or even days after the original filing is received by the court. While one or more asynchronous confirmations must be sent in response to a filing, there is no requirement to send asynchronous confirmations to notices. [24] As a general rule, service providers are not expected to provide an asynchronous means of electronic filing, although they may do so. An example of synchronous filing is electronic filing over HTTP, where a synchronous confirmation is as part of one HTTP transaction. An example of asynchronous filing is electronic filing via email or on a disk, where the first response to the filing is a separate transaction (i.e., an asynchronous confirmation). In the latter situation, a synchronous confirmation is not possible. An exception to the general rule would be in situations where a filing were very large or if many filings were delivered at the same time. If the total number of bytes is large, it may not be possible, as a practical matter, to send electronic filings over a network connection. In this situation, it may be necessary to transmit electronic filings on computer disks or other read/write media. [25] In a synchronous confirmation situation, a receiving application must: (a) receive the Filing XML; (b) validate the Filing XML against the Filing schema (called schema validation); (c) (optionally) programmatically check to ensure that data required by the court is present, such as one plaintiff and one defendant or that the court specified is the correct court (called policy validation if done against Policy XML or code/programmatic validation otherwise); and (d) create and validate Confirmation XML and send it back to the sending application over the same, unbroken HTTP connection. [26] In a synchronous confirmation situation, if Plug-In XML is used in the Case:DataFile or Document:DataFile elements, then (after validating the Filing XML or Notice XML) applications must (a) extract or otherwise isolate the Plug-In XML from the Filing XML or Notice XML and (b) validate the Plug-In XML against the appropriate schema. If schema validation fails for either the Filing XML, Notice XML (first pass) or the Plug-In XML (second pass), then the receiving application must send back an error message using Confirmation XML. [27] In an asynchronous confirmation situation, an application must send an asynchronous confirmation after the filing transaction occurs at the appropriate point during the electronic acceptance/rejection process (e.g. clerk review). Asynchronous confirmations may be sent via HTTP to the sending application (or ReplyTo application) if the sending application has a means of accepting HTTP confirmations and has included a URI in the Header:ReplyTo element of the filing's Header XML. Asynchronous confirmations may also be sent via SMTP. See the Confirmation schema and Header schema for more information. Confirmation Acknowledgement[28] A confirmation acknowledgement is a response to an asynchronous confirmation. An application is not required to send a confirmation acknowledgment, but may do so. If an application sends a confirmation acknowledgment, the application must send valid Confirmation XML as defined in this specification with as few elements as possible. If the transaction is successful, then the confirmation acknowledgement's Confirmation:FilingStatus value must be equal to Received. If the transaction is unsuccessful, then the Confirmation:FilingStatus must be equal to Error. If an error occurs, the receiving application or intermediary application (i.e., on a court server or an intermediary server) is not responsible sending another Confirmation XML, but may do so. Dates and Times in Filing XML and Confirmation XML[29] The following table summarizes dates and times in Confirmation XML and Header XML as those dates and times relate to Filing XML. Elements | Filing | Confirmation Synchronous (Received) | Confirmation Synchronous (Error) | Confirmation Asynchronous (Accepted) | Confirmation Asynchronous (Rejected) |
---|
Header:Date/Time | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Filing:Date/Time | Filer's assertion of when filed | N/A | N/A | N/A | N/A | Confirmation:Date/Time | N/A | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Confirmation:FilingDate and Confirmation:FilingTime | N/A | Mirror Filer's assertion of when filed | If available, mirror Filer's assertion of when filed. Otherwise, moment of generation | Court's determination of when filed (often based on the date/time of reception) | Court's determination of when filed (often based on the date/time of reception) |
[30] Moment of generation is the moment the XML is created and then sent, assuming the creation-time and sending-time are close in time (i.e., within seconds or minutes). If the XML is created at a time that is significantly different than when it is sent, then the XML must be edited prior to sending to reflect a date and time as close as possible to the sending date and time. [31] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. Base64-Encoding and Links[32] Electronic documents can be transmitted in Filing XML using either base64-encoding or links. This section outlines general rules about links and base64-encoding. [33] (a) Neither base64-encoding nor links are clearly better than the other. Each approach has advantages and disadvantages that make it more or less suitable for a given filing environment. Implementers must understand requirements and then decide the better technology to use in a given environment. [34] (b) Base64-encoding is generally simpler than links. Links is more complicated. [35] (c) Links performs better than base64-encoding. Links is better for transmitting large documents and filings (over 250-500 KB). [36] (d) Sending and receiving applications are encouraged to implement and support both approaches. [37] More detailed information can be found in the Document schema documentation. Identification, Authentication and Security[38] 2GEFS Participants have agreed to the following rules regarding filer identification and authentication, but actual practice is a matter of local policy. Note that policy decisions in this regard may help or hinder interoperability. [39] (a) 2GEFS Participants distinguish identification from authentication. Identification is determining the name, social security number, taxpayer number, or other information that unambiguously distinguishes a person or entity from other people and entities. Authentication is verifying identification information. At a minimum, service providers must identify filers. Service providers may also wish to authenticate the identity of filers. Service providers may authenticate filers using any means. [40] (b) The identification and authentication process for filers should be as simple as possible with the fewest barriers balanced by reasonable security precautions. [41] (c) Any identification or authentication regime should be service provider neutral. That is, filers should not be bound to a service provider by way of an identifier or authentication regime.
[42] (d) Service providers are not required to authenticate filers on behalf of courts, but must provide some type of filer identification to the court. Filer identification may be done by first and last name, bar number, social security number, federal taxpayer identification number, or other means acceptable to the court. Individual courts, on a case-by-case basis, may decide the type of identifier it requires. As a matter of state or local policy, courts may contractually obligate service providers to authenticate filers. [43] (e) Service providers must authenticate their software to the court. This can be done using web server username/password authentication, IP filtering, or other types of web-based authentication. Service providers and courts are encouraged to use SSL to encrypt transactions. [44] Username/password elements are included in Header XML. Other security or authentication information may be provided using W3C XML Signature, W3C XML Encryption, or related technologies. Elements of a Filing[45] The Filing element is the intended root element of the schema. [46] Filing must contain one of each of the following elements: Filing:Key, Filing:Date, Filing:Time, Filing:Case, Filing:CourtDetails, Filing:Filers, Filing:PolicyVersion, and Filing:RunMode. [47] Filing must contain one LeadDocuments/LeadDocument element, but may contain several. This is not to say that there may be more than one logical lead documents; rather, the purpose is to allow one lead document to be simultaneously filed in different electronic formats, such as Adobe PDF and TIFF. See Filing:LeadDocument and the Document schema for more information. [48] Filing may contain Filing:LegacyCases, Filing:People, Filing:Organizations, Filing:Things, Filing:Charges, Filing:Coversheet, Filing:Attachments, Filing:Fees, Filing:Payment, Filing:Services, Filing:Calendars, Filing:Extensions, Filing:Confidential, Filing:Sealed, and Filing:Message.
Schema Framework[49] All 2GEFS XML Schema are, or are constructed from, XML "primitives" or "building blocks" that conform to a consistent set of rules. These rules are documented in the Schema Framework, which is a set of best practices and rules for developing XML Schemas. The Schema Framework ensures that building blocks can be assembled into more complex and versatile XML structures. The Schema Framework also provides version control, unique schema identifiers, support for schema management and maintenance services, and consistent publishing rules for schema discovery and documentation. The Schema Framework is not one schema, but rather a standard and consistent Framework of many schemas. [50] For example, the Schema Framework provides a standard way to create different Address schemas or a variety of more complex Court Filing schemas depending on the needs of a particular jurisdiction or the specific requirements of applications within a jurisdiction. This approach serves the needs of different jurisdictions and organizations that have similar but varied requirements. The use of the Schema Framework makes it easier for developers to code around and understand schemas, yet provides the flexibility to serve the varying needs of government, lawyers, vendors, and citizens. Attribute(s) | type | use | fixed/default | ReceivedDate | xsd:date | optional | None |
[51] Filing:Date is the filer's assertion of the date of the filing. This is not the date that the court acknowledges receipt, although the dates may be the same or very close in time. If the court accepts the filer's assertion of the date of filing, then the Confirmation:FilingDate may be the same as the Filing:Date, at the discretion of the court. The Filing:Date is not the same as the transmission date, although these date values may be the same or very close in time. Filing:Date is not a date from the document. Filing:Date is not the date of service of process. [52] The ReceivedDate attribute is not for use by sending applications, but instead by receiving applications. Receiving application may use this attribute to record the date on which the application received the Filing XML. Attribute(s) | type | use | fixed/default | ReceivedTime | xsd:time | optional | None |
[53] Filing:Time is the filer's assertion of the time of the filing. This is not the time that the court acknowledges receipt, although the times may be the same or very close in time. If the court accepts the filer's assertion of the time of filing, then the Confirmation:FilingTime may be the same as the Filing:Time, at the discretion of the court. The Filing:Time is not the same as the transmission time, although these time values may be the same or very close in time. [54] The ReceivedTime attribute is not for use by sending applications, but instead by receiving applications. Receiving application may use this attribute to record the time on which the application received the Filing XML. [55] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. Child Element(s) | minOccurs | maxOccurs | LegacyCase | 1 | unbounded |
[56] Filing:LegacyCases is a container element for one or more Filing:LegacyCase elements. Child Element(s) | minOccurs | maxOccurs | Filer | 1 | unbounded |
[57] Filing:Filers is a container element for one or more Filing:Filer elements. The filer's information must not be duplicated in Filing:People or Filing:Organizations.
[58] Filing:Filer contains information about who filed the case. Filing:Filer may be a Person or an Organization. A person is a natural person. An organization is a legal entity, such as a corporation, a limited liability company, or a government subdivision. [59] Specific courts and jurisdictions should define business rules for this element. There are a number of options for the meaning: (a) Filing:Filer could be the exact person who files the document, such as a legal secretary or a lawyer, (b) Filing:Filer could be a lawyer, even though the actual person who clicks the button and files the document is the lawyer's legal secretary, (c) Filing:Filer could be the firm for which a lawyer works, even though a lawyer or a lawyer's legal secretary actually clicks the button and files the document or (d) Filing:Filer could be the party on whose behalf a lawyer or law firm files a document. If it is unknown which of the above policies applies in a court, then, if more than one Filing:Filer element exists, applications should consider the information in the first Filing:Filer element as the primary or only filer (depending on how many filers the application can accept). For example, the CMS-API specification (as of this writing) only allows one "FiledByParty" when adding a document to a CMS. [60] The Person and Role schemas can be used to assign additional roles to the filer (such as Attorney, Plaintiff, or Defendant) and associate filers and other people and organizations. As a result, the filer does not need to be, and must not be, duplicated in the Filer:Person or Filer:Organization elements. [61] Additionally, the Document:FiledBy and Document:RefersTo elements can be used to associated parties with documents. Child Element(s) | minOccurs | maxOccurs | Person | 1 | unbounded |
[62] Filing:People is a container element for one or more Filing:Person elements. Filing:People are all of the people, whether parties, officials, or judges, associated with the case. [63] On case initiation (e.g., a filing without a Case:Number), this element should be populated with all of the parties, officials, and other people relevant to the case. This information should then be passed to the CMS, usually with clerk review, via the CMS-API or Request/Response XML. In subsequent filings, this information should not be populated unless new people have been added to the case or information for existing people is meant to be updated. Applications, using the CMS-API, should check to see whether people already exist in the CMS and should not insert people twice or should provide the clerk the opportunity to add, delete, or update people as appropriate.
[64] Filing:Organizations is a container element for one or more Filing:Organization elements. Filing:Organizations are all of the organizations, whether parties, state agencies, or others, associated with the case. [65] On case initiation (e.g., a filing without a Case:Number), this element should be populated with all of the organizations relevant to the case. This information should then be passed to the CMS, usually with clerk review, via the CMS-API or Request/Response XML. In subsequent filings, this information should not be populated unless new organizations have been added to the case or information for existing organizations is meant to be updated. Applications, using the CMS-API, should check to see whether organizations already exist in the CMS and should not insert organizations twice or should provide the clerk the opportunity to add, delete, or update organizations as appropriate. Child Element(s) | minOccurs | maxOccurs | Thing | 1 | unbounded |
[66] Filing:Things is a container element for one or more Filing:Thing elements. A Filing:Thing is an animal or inanimate object (i.e., not a legal entity) that has been made a party to a case. [67] Including a thing as a party to a case is called in rem jurisdiction. In rem jurisdiction is sought in situations where a real person or organization (e.g., a legal entity) is not within the jurisdiction of the court and a plaintiff wants to gain financial or physical control over the property or thing. In this case, the "thing" being sued would be, for example, a boat, a car, a bank account, a house, or a goat. [68] On case initiation (e.g., a filing without a Case:Number), this element should be populated with all of the things that have been made a party to a case (but not things, such as physical evidence). This information should then be passed to the CMS, usually with clerk review, via the CMS-API or Request/Response XML. In subsequent filings, this information should not be populated unless new things have been added to the case or information for existing things is meant to be updated. Applications, using the CMS-API, should check to see whether things already exist in the CMS and should not insert things twice or should provide the clerk the opportunity to add, delete, or update things as appropriate. Child Element(s) | minOccurs | maxOccurs | Charge | 1 | unbounded |
[69] Filing:Charges is a container element for one or more Filing:Charge elements. A Filing:Charge is the details of an offense or complaint in a criminal, juvenile, or other criminal-like case. Filing:Charge will not usually be used in civil cases. See the Charge schema.
[70] Filing:LeadDocuments is a container element for one or more Filing:LeadDocument elements. A Filing:LeadDocument is the primary and most important document in a filing. A filing may contain several Filing:LeadDocument elements; however, it may contain only one logical lead document. The purpose of allowing multiple Filing:LeadDocument elements is to allow one logical lead document to be simultaneously filed in different electronic document formats, such as Adobe PDF and Microsoft Word. For example, a filer might submit a Motion for Summary Judgment as both a Microsoft Word document and as an Adobe PDF document, so that the court has both an editable version and a static version of the document. See the Filing:LeadDocument element. Child Element(s) | minOccurs | maxOccurs | Attachment | 1 | unbounded |
[71] Filing:Attachments is a container element for one or more Filing:Attachment elements. A Filing:Attachment is a secondary document, as described in Filing:LeadDocument. Other than its meaning, Filing:Attachment works in the same way as Filing:LeadDocument, except that Filing:Attachment can and should have different Document:Key values. See Filing:LeadDocument and Document schema. Child Element(s) | minOccurs | maxOccurs | Fee | 1 | unbounded |
Attribute(s) | type | use | fixed/default | FeeTotal | xsd:string | required | None |
[72] Filing:Fees is a container element for one or more Filing:Fee elements. Filing:Fees must include each individual fee submitted by the filer to the court. The total amount of the fees, whether there is only one fee or multiple fees, must be included in the required attribute FeeTotal. See the Fee schema. Child Element(s) | minOccurs | maxOccurs | Service | 1 | unbounded |
[73] Filing:Services is a container element for one or more Filing:Service elements. A Filing:Service element represents one service of process event. To express more than one service of process event, applications must use more than one Filing:Service elements. See Filing:Service element. Child Element(s) | minOccurs | maxOccurs | Calendar | 1 | unbounded |
[74] Filing:Calendars is a container element for one or more Filing:Calendar elements. A Filing:Calendar element represents multiple calendar events on a single day for a given court department. To express multiple calendar events on a single day for a single court department, applications must use only one Filing:Calendar element. To express multiple days, applications must use multiple Filing:Calendar elements. To express events taking place in different departments, applications must also use multiple Filing:Calendar elements. See Filing:Calendar element. Child Element(s) | minOccurs | maxOccurs | Extension | 1 | unbounded |
[75] Filing:Extensions is a container element for one or more Filing:Extension elements. A Filing:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. The Filing:Extension element may include a SendBack attribute value equal to Yes. Receiving applications that encounter a SendBack value equal to Yes must send back the exact name/value pair in Confirmation:Extension element. See the Extension schema. [76] Filing:Confidential is an optional element of type boolean. When set to true, Filing:Confidential means that the filer believes there is a statutory reason that the filing should remain confidential and should not be published to the public. The receiving application should behave according to policy set by the court. [77] If the Filing:Confidential element value is equal to true, then all documents in a filing are requested to be confidential. As a result, if the Filing:Confidential element value is equal to true, then the Document:Confidential element must be absent or it must be ignored, if present. [78] Filing:Sealed is an optional element of type boolean. When set to true, Filing:Sealed means that the filer believes there is a statutory reason that the filing should be sealed by the court and not be published either to the public or to the court clerk. Filing:Sealed is distinguished from Filing:Confidential in that Filing:Confidential is merely a filer's request to keep the filing confidential from the public, whereas Filing:Sealed is a filer's request to keep the filing sealed from the public and the court clerk. Only a judge would be able to review the filing. The receiving application should behave according to policy set by the court. [79] If the Filing:Sealed element value is equal to true, then all documents in a filing are requested to be sealed. As a result, if the Filing:Sealed element value is equal to true, then the Document:Sealed element must be absent or it must be ignored, if present.
[80] The Filing:PolicyVersion is the version number of the Policy XML used to create the Filing XML. If a Policy XML file was not used, then use the version 0.0.0. [81] The Filing:PolicyMajorVersion element is the major version number of the Policy XML used to create the Filing XML. [82] The Filing:PolicyMinorVersion element is the minor version number of the Policy XML used to create the Filing XML. [83] Filing:RunMode is a single element with two possible values: Test or Live. Filing:RunMode is used when sending test filings to a live server so that downstream applications or the court clerk will know to ignore or behave differently toward the test filing. The element may also be useful in situations where test filings into a live server need to be purged mechanically, rather than deleted manually. [84] Applications are urged to implement Filing:RunMode in both test and live systems. When migrating from a test environment to a live environment, this element allows applications to send and receive filings and confirmations in a live system, while retaining the ability to identify a filing or a confirmation as a test. The ability to send and receive test filings and confirmations in a live system is helpful in the final stages of going live with an electronic filing system. [85] Filing:Message is a message intended to be conveyed to the court from the filer on any topic. [86] Filing:Key is a unique identifier for the filing. See the Key schema. [87] Filing:Case contains information about the case being filed. This information is primarily used for case initiation. See the Case schema. [88] Filing:LegacyCase contains information about a case with a case number that is associated with, and a predecessor of, Filing:Case. For example, if a case is appealed, then the original case information can be included in Filing:LegacyCase when filing a new case. See the Case schema. [89] Filing:CourtDetails contains information about the court into which documents are being filed. Importantly, Filing:CourtDetails includes CourtDetails:OrganizationKey and CourtDetails:CourtKey, which are unique identifiers for the court and for divisions within the court. Filing applications should copy this information from the court's Policy XML. See the CourtDetails schema. [90] Filing:Person contains information about a person that is a party to a case or is otherwise associated with a case. See Filing:People documentation. See the Person schema. [91] Filing:Organization contains information about an organization that is a party to a case or is otherwise associated with a case. See Filing:Organizations documentation. See the Organization schema. [92] Filing:Thing contains information about a thing that is a party to a case. See Filing:Things documentation. See the Thing schema. [93] Filing:Charge contains information about a charge. See Filing:Charges documentation. See the Charge schema. [94] Filing:Fee contains information about a court filing fee. Filing applications should copy this information from the court's Policy XML. See the Filing:Fees element, the Fee schema and the Policy XML specification. [95] Filing:Service contains information about documents for which service of process has taken place. See the service Schema. [96] Filing:Coversheet contains a filing coversheet document, if any. Filing:Coversheet is not a lead document and is not an attachment. The actual document should be included in the Document:Pages element. Associated data, if any, should be put in the Document:DataFile element. "Associated Data" would be information collected on the coversheet that is not defined in Filing XML. For example, Filing XML does not define specific data for all filing types, such as Small Claims filings. To collect data specific to Small Claims, for example, it is suggested that developers (a) define a schema for Small Claims data that represents the data collected on a Small Claims coversheet (b) require the filing application to collect Small Claims data using the coversheet or by other means (c) require the filing application to base64 encode, in this case, Small Claims XML, that validates against a Small Claims Schema and put the base64-encoded content in the Document:DataFile element. A receiving application would then check the Document:GenericType element and would invoke a special processing rule to decode the base64, validate the XML, and process the data appropriately. For example, if the Document:GenericType value were Small Claims Coversheet, the receiving application would know to process the Document:DataFile contents in a special way. [97] Filing:LeadDocument is the primary and most important document in a filing. For example, if a party is filing a Motion for Summary Judgment supported by an Affidavit and two Exhibits, then the Motion would be the lead document and the other three documents would be attachments. [98] It is possible to have more than one Filing:LeadDocument elements although there can only be one logical lead document. The ability to use multiple Filing:LeadDocument elements is so that the same document can be transmitted in several different electronic formats, such as Microsoft Word and Adobe PDF. There is an arbitrary limit of four Filing:LeadDocument elements that can be used as it is unlikely that more than four electronic document formats of the same document will be sent to a court. [99] Multiple Filing:LeadDocument elements should not be used to send data files associated with a document. For example, it is not permissible to send a Microsoft Word document in one Filing:LeadDocument along with an associated data file containing data within the Microsoft Word document in another Filing:LeadDocument. It is possible to send a document and associated data file using the Document:DataFile element. [100] The Document:Key for each Filing:LeadDocument must be the same. Applications that receive different Document:Key values must use the value from the first Filing:LeadDocument and may ignore other documents. See the Document schema. [101] Filing:Attachment contains information about a secondary document. See the Filing:LeadDocument and Filing:Attachments elements. [102] A Filing:Payment provides information about a filer's credit card so that a filer can pay a service provider or the court directly. See the Payment schema. [103] A Filing:Calendar provides information about calendared events. See the Calendar schema. [104] A Filing:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. See the Filing:Extensions element. |