Second Generation Electronic Filing Specifications
 

Staff and Consultants
Winchel "Todd" Vincent III, Author
WTVIII, Inc. and <xmlLegal>
Todd.Vincent@xmllegal.org
Christopher Smith,
Senior Business Systems Analyst
California Administrative Office of the Courts
christopher.smith@jud.ca.gov
 
Filing Schema
Last Updated: 2008-11-13
 

Schema Namespace and Documentation
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/
Schema Prefix
Filing
Schema Repository Location
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Filing.xsd
 
Table of Contents
1. Elements
 Internal
  1.1. Filing
  1.2. Date
  1.3. Time
  1.4. LegacyCases
  1.5. Filers
  1.6. Filer
  1.7. People
  1.8. Organizations
  1.9. Things
  1.10. Charges
  1.11. LeadDocuments
  1.12. Attachments
  1.13. Fees
  1.14. Services
  1.15. Calendars
  1.16. Extensions
  1.17. Confidential
  1.18. Sealed
  1.19. PolicyVersion
  1.20. PolicyMajorVersion
  1.21. PolicyMinorVersion
  1.22. RunMode
 External
  1.23. Message
  1.24. Key
  1.25. Case
  1.26. LegacyCase
  1.27. CourtDetails
  1.28. Person
  1.29. Organization
  1.30. Thing
  1.31. Charge
  1.32. Fee
  1.33. Service
  1.34. Coversheet
  1.35. LeadDocument
  1.36. Attachment
  1.37. Payment
  1.38. Calendar
  1.39. Extension
2. Simple Types
  2.1. VersionNumber
  2.2. RunModes
3. Imported Schemas
  3.1. Attributes
  3.2. CourtDetails
  3.3. Extension
  3.4. Fee
  3.5. Key
  3.6. Organization
  3.7. Person
  3.8. Thing
  3.9. Calendar
  3.10. Case
  3.11. Charge
  3.12. Document
  3.13. Message
  3.14. Payment
  3.15. Service
4. Change History
  4.1. 2003-02-18
  4.2. 2003-03-01
  4.3. 2003-06-14
  4.4. 2003-06-14
  4.5. 2003-06-14
  4.6. 2003-06-15
  4.7. 2003-07-23
  4.8. 2003-07-26
  4.9. 2003-07-27
  4.10. 2003-07-29
  4.11. 2004-02-29
  4.12. 2004-03-25
  4.13. 2004-04-26
  4.14. 2004-04-30
  4.15. 2004-05-10
  4.16. 2004-08-02
  4.17. 2004-08-05
  4.18. 2004-09-14
  4.19. 2005-06-25
  4.20. 2005-12-03
  4.21. 2008-09-30
  4.22. 2008-11-13
5. Legal Notices
6. Authors and Contributors

1. Elements

1.1. Filing:Filing
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Key11
Date11
Time11
Case11
LegacyCases01
CourtDetails11
Filers11
People01
Organizations01
Things01
Charges01
Coversheet01
LeadDocuments11
Attachments01
Fees01
Payment01
Services01
Calendars01
Extensions01
Confidential01
Sealed01
Message01
PolicyVersion11
RunMode11

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.

ElementsFilingConfirmation Synchronous (Received)Confirmation Synchronous (Error)Confirmation Asynchronous (Accepted)Confirmation Asynchronous (Rejected)
Header:Date/TimeMoment of generationMoment of generationMoment of generationMoment of generationMoment of generation
Filing:Date/TimeFiler's assertion of when filedN/AN/AN/AN/A
Confirmation:Date/TimeN/AMoment of generationMoment of generationMoment of generationMoment of generation
Confirmation:FilingDate and Confirmation:FilingTimeN/AMirror Filer's assertion of when filedIf available, mirror Filer's assertion of when filed. Otherwise, moment of generationCourt'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.

1.2. Filing:Date
Data Type: xsd:date
go to top
Attribute(s)typeusefixed/default
ReceivedDatexsd:dateoptionalNone

[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.

1.3. Filing:Time
Data Type: xsd:time
go to top
Attribute(s)typeusefixed/default
ReceivedTimexsd:timeoptionalNone

[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.

1.4. Filing:LegacyCases
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
LegacyCase1unbounded

[56]  Filing:LegacyCases is a container element for one or more Filing:LegacyCase elements.

1.5. Filing:Filers
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Filer1unbounded

[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.

1.6. Filing:Filer
Content Model: choice
go to top
Child Element(s)minOccursmaxOccurs
Person11
Organization11

[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.

1.7. Filing:People
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Person1unbounded

[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.

1.8. Filing:Organizations
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Organization1unbounded

[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.

1.9. Filing:Things
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Thing1unbounded

[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.

1.10. Filing:Charges
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Charge1unbounded

[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.

1.11. Filing:LeadDocuments
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
LeadDocument14

[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.

1.12. Filing:Attachments
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Attachment1unbounded

[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.

1.13. Filing:Fees
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Fee1unbounded

Attribute(s)typeusefixed/default
FeeTotalxsd:stringrequiredNone

[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.

1.14. Filing:Services
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Service1unbounded

[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.

1.15. Filing:Calendars
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Calendar1unbounded

[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.

1.16. Filing:Extensions
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Extension1unbounded

[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.

1.17. Filing:Confidential
Data Type: xsd:boolean
go to top

[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.

1.18. Filing:Sealed
Data Type: xsd:boolean
go to top

[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.

1.19. Filing:PolicyVersion
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
PolicyMajorVersion11
PolicyMinorVersion22

[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.

1.20. Filing:PolicyMajorVersion
Data Type: VersionNumber
go to top

[81]  The Filing:PolicyMajorVersion element is the major version number of the Policy XML used to create the Filing XML.

1.21. Filing:PolicyMinorVersion
Data Type: VersionNumber
go to top

[82]  The Filing:PolicyMinorVersion element is the minor version number of the Policy XML used to create the Filing XML.

1.22. Filing:RunMode
Data Type: RunModes
go to top

[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.

1.23. Filing:Message
Data Type: Message:Message
go to top

[85]  Filing:Message is a message intended to be conveyed to the court from the filer on any topic.

1.24. Filing:Key
Data Type: Key:Key
go to top

[86]  Filing:Key is a unique identifier for the filing. See the Key schema.

1.25. Filing:Case
Data Type: Case:Case
go to top

[87]  Filing:Case contains information about the case being filed. This information is primarily used for case initiation. See the Case schema.

1.26. Filing:LegacyCase
Data Type: Case:Case
go to top

[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.

1.27. Filing:CourtDetails
Data Type: CourtDetails:CourtDetails
go to top

[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.

1.28. Filing:Person
Data Type: Person:Person
go to top

[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.

1.29. Filing:Organization
Data Type: Organization:Organization
go to top

[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.

1.30. Filing:Thing
Data Type: Thing:Thing
go to top

[92]  Filing:Thing contains information about a thing that is a party to a case. See Filing:Things documentation. See the Thing schema.

1.31. Filing:Charge
Data Type: Charge:Charge
go to top

[93]  Filing:Charge contains information about a charge. See Filing:Charges documentation. See the Charge schema.

1.32. Filing:Fee
Data Type: Fee:Fee
go to top

[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.

1.33. Filing:Service
Data Type: Service:Service
go to top

[95]  Filing:Service contains information about documents for which service of process has taken place. See the service Schema.

1.34. Filing:Coversheet
Data Type: Document:Document
go to top

[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.

1.35. Filing:LeadDocument
Data Type: Document:Document
go to top

[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.

1.36. Filing:Attachment
Data Type: Document:Document
go to top

[101]  Filing:Attachment contains information about a secondary document. See the Filing:LeadDocument and Filing:Attachments elements.

1.37. Filing:Payment
Data Type: Payment:Payment
go to top

[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.

1.38. Filing:Calendar
Data Type: Calendar:Calendar
go to top

[103]  A Filing:Calendar provides information about calendared events. See the Calendar schema.

1.39. Filing:Extension
Data Type: Extension:Extension
go to top

[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.

2. Simple Types

2.1. VersionNumber
Data Type: xsd:integer
maxInclusive: 9
minInclusive: 0
go to top
2.2. RunModes
Data Type: xsd:string
go to top
Enumeration(s)

Value
Test
Live

3. Imported Schemas

3.1. Attributes
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Attributes/03/
  
3.2. CourtDetails
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/CourtDetails/03/
  
3.3. Extension
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Extension/03/
  
3.4. Fee
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Fee/03/
  
3.5. Key
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Key/03/
  
3.6. Organization
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Organization/03/
  
3.7. Person
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Person/03/
  
3.8. Thing
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Thing/03/
  
3.9. Calendar
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Calendar/01/
  
3.10. Case
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Case/01/
  
3.11. Charge
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Charge/01/
  
3.12. Document
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Document/01/
  
3.13. Message
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Message/01/
  
3.14. Payment
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Payment/01/
  
3.15. Service
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Service/01/
  

4. Change History

4.1. 2003-02-18
Editor: Winchel Vincent
go to top

Added structured copyright and update history.

4.2. 2003-03-01
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Filing/02/
go to top

Copied.

4.3. 2003-06-14
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Filing/Test01/
go to top

Copied. Removed extra min and maxOccurs.

4.4. 2003-06-14
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Filing/Tests/Filing/Test01/
go to top

Copied. Changed People content model from choice to sequence.

4.5. 2003-06-14
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Filing/Tests/Filing/Test02/
go to top

Copied. Added RunMode element, complexType and documentation. Added RunModes simpleType. Created container element, LeadDocuments.

4.6. 2003-06-15
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.0.9.

4.7. 2003-07-23
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test01/
go to top

Copied. Eliminated Date.xsd and Time.xsd and included xsd:date and xsd:time. Added Payment Schema.

4.8. 2003-07-26
Editor: Winchel Vincent
go to top

Added Calendar schema. Changed Key, CourtDetails, and Extension namespaces and import locations to reflect move of schema to Building Block folder.

4.9. 2003-07-27
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.0.9. Changed Person and Organization namespaces.

4.10. 2003-07-29
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test02/
go to top

Copied.

4.11. 2004-02-29
Editor: Winchel Vincent
go to top

Updated documentation. Added introductory explanation and links to CA AOC website and schema repositories. Added information about the Schema Framework. Clarified use of SOAP. Edited synchronous and asynchronous filing and confirmation paragraphs for clarity. Clarified paragraphs about identification and authentication of filers. Changed SHTTP to HTTPS. Added explanatory text about use of Person and PersonRole schema when associating filers. Added clarification regarding clerk review before data is inserted into a CMS. Corrected typographical errors.

4.12. 2004-03-25
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test03/
go to top

Copied.

4.13. 2004-04-26
Editor: Winchel Vincent
go to top

Added Filing:Message to be consistent with Confirmation:Message. Added documentation to for Filing:Message. Made Filing:Message a Memo simpleType. Added Memo simpleType. Added new Filing:LegacyCases and Filing:LegacyCase. For readability purposes, rearranged the order of Filing:Fees and Filing:Service so that Filing:Fees would exist next to Filing:Payment and so that Filing:Service information would exist lower. Softened language in introduction that requires programmatic checking of a Plaintiff and Defendant. Documentation now states that this programmatic checking is optional. Made minor changes to documentation. Changed Key schema 01 to Key schema 02.

4.14. 2004-04-30
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.1.0.

4.15. 2004-05-10
Editor: Winchel Vincent
go to top

Made minor typographical changes. Added headings.

4.16. 2004-08-02
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test04/
go to top

Copied. Changed primitive schemas namespace versions from 01 to 02.

4.17. 2004-08-05
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.1.0.

4.18. 2004-09-14
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test05/
go to top

Copied.

4.19. 2005-06-25
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/01/
go to top

Copied. Changed imported schemas and attributes to 03 version. Added Filing:Sealed. Added Filing:Services element. Added Filing:Calendars element. Added required FeeTotal attribute.

4.20. 2005-12-03
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test06/
go to top

Copied.

4.21. 2008-09-30
Editor: Winchel Vincent
go to top

Message schema added. Filing:Message changed from xsd:string to Message:Message. Added Filing:PolicyVersion, Filing:PolicyMajorVersion, Filing:PolicyMinorVersion.

4.22. 2008-11-13
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test07/
go to top

Copied. Added @ReceivedDate and @ReceivedTime to Filing:Date and Filing:Time, respectively. Added VersionNumber simpleType. Change Filing:PolicyMajorVersion and Filing:PolicyMinorVersion to type VersionNumber from xsd:string. Removed Memo simpleType. New attributes ReceivedDate and ReceivedTime added to the elements Filing:Date and Filing:Time.

5. Legal Notices

Unless otherwise agreed, All Rights Reserved except those granted by xmlLegal General Public License at:

LICENSED WORKS ARE PROVIDED "AS IS," AND HOLDERS OF INTELLECTUAL PROPERTY RIGHTS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE LICENSED WORKS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

HOLDERS OF INTELLECTUAL PROPERTY WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE LICENSED WORKS.

Contact Winchel "Todd" Vincent III (Todd.Vincent@xmllegal.org) or xmlLegal Help (help@xmllegal.org) for more information.

6. Authors and Contributors


Staff and Consultants
Winchel "Todd" Vincent, III, Author
WTVIII, Inc. and <xmlLegal>
Todd.Vincent@xmllegal.org
Kevin Stannard, Original Editor
Swiftnet Solutions, Ltd.
kevin.stannard@swiftnet-solutions.com
Charlene Hammitt, Project Director
California Administrative Office of the Courts
charlene.hammitt@jud.ca.gov
Christopher Smith, Senior Business Systems Analyst
California Administrative Office of the Courts
christopher.smith@jud.ca.gov
Tom Smith, Consultant
AVI/IT Decision
tjsmith@itdecision.com
Courts
Contra Costa Superior Court (http://cc-courts.org/)
Kathy Ridgeway, KRIDG@sc.co.contra-costa.ca.us
Karen Ortega, KORTE@sc.co.contra-costa.ca.us
Orange Superior Court (http://www.occourts.org/)
Allen Jensen, ajensen@occourts.org
SacramentoSuperior Court (http://www.saccourt.com/)
Doug Kauffroath, KauffrD@saccourt.com
Ryan Hurlock, HurlocR@saccourt.com
Judith Kerrin, KerrinJ@saccourt.com
Marcia Barclay, BarclaM@saccourt.com
Huldeni "Zito" Souza, SouzaH@saccourt.com
Michael Alexander, AlexanM@saccourt.com
Gary Nishi, NishiG@saccourt.com
San Mateo Superior Court (http://www.sanmateocourt.org/)
Tim Benton, tbenton@co.sanmateo.ca.us
Rick Walery, rwalery@sanmateocourt.org
Bill Harven, wharven@sanmateocourt.org
Carrie Warren, cwarren@sanmateocourt.org
Santa Clara Superior Court (http://www.sccsuperiorcourt.org/)
Barry Lynch, blynch@scscourt.org
Deborah Barker, dbarker@scscourt.org
Francine Collier, fcollier@scscourt.org
 
Contributors
counterclaim, inc. (http://www.counterclaim.com)
Shogan Naidoo, shogan@counterclaim.com
Michelle Naidoo, mnaidoo@counterclaim.com
Jim Beard, beard@counterclaim.com
Jason Van Cleve, jason@vancleve.com
Deloitte Consulting (http://www.deloitte.com/)
Bruce Scheffle, bscheffel@deloitte.com
E-Filing.com (http://www.e-filing.com)
Mohammed Shaikh, mohammed@e-filing.com
Amrit Singh Nandrey, amrit@imagexx.com
Prabhath Pallati, prabhath@imagexx.com
Essential Publishers (http://www.essentialpublishers.com)
Martin Dean, dean@epubs.org
George Rothbart, george@softsci.com
Glotrans (http://www.glotrans.com)
Andy Jamieson, ajam@glotrans.com
Conor Dixon, conordixon@comcast.net
Intresys (http://www.intresys.com)
Yegor Borovikov, yegorb@intresys.com
Tania Wasser, taniaw@intresys.com
ISD Corporation (http://www.essentialpublishers.com)
Rob Beach, Ron.Beach@isd-corp.com
Holly Ramirez, Holly.Ramirez@isd-corp.com
John Coughlin, john.coughlin@isd-corp.com
Bob Gehringer, bob.gehringer@isd-corp.com
Robert Entrican, robert@entrican.com
Lexis-Nexis (http://www.lexisnexis.com)
Jonathan Gill, jonathan.gill@lexisnexis.com
Shane Durham, shane.durham@lexisnexis.com
One Legal, Inc. (http://www.onelegal.com)
Robert DeFilippis, rtd@onelegal.com
Matt Marshall, matt@mattmarshall.com
Bryan Barringer, bbarringer@onelegal.com
Bill Porterfield, billp@servicehub.com
Patrick Zanone, patrick.zanone@macroburst.com
U.S. Court Forms/American LegalNet (http://www.uscourtforms.com)
Erez Bustan, erez@uscourtforms.com
Kin Lee, kin@uscourtforms.com
Harry Thakkar, Hthakkar@uscourtforms.com