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
 
Confirmation Schema
Last Updated: 2008-11-13
 

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

1. Elements

1.1. Confirmation:Confirmation
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Numbers01
Date11
Time11
FilingStatus11
FilingKey01
FilingDate01
FilingTime01
Case01
LegacyCases01
CourtDetails01
Filers01
People01
Organizations01
Things01
Charges01
Coversheet01
LeadDocuments01
Attachments01
Fees01
Payment01
Services01
Calendars01
Extensions01
Confidential01
Sealed01
Messages01
Errors01
RunMode11

Introduction

[1]  The Confirmation element is the intended root element of the schema. The confirmation mirrors the elements in a filing, except that a confirmation also includes Confirmation:Number, Confirmation:Date, Confirmation:Time, Confirmation:FilingStatus and Confirmation:Error.

Rules for Mirroring Filing XML in Confirmation XML

[2]  Elements in the confirmation mirror elements in a filing based on the assumption that filing information may change as the Filing XML travels downstream from a filing application to the court. In case the information changes, or even if it does not, the confirmation serves as a receipt and notice of the information ultimately accepted by the court. There is a corresponding element in a confirmation for every element in a filing so that changed information can be communicated to the filing application. For example, the filing application may include an incorrect or incomplete value for a case category. The clerk of court or the EFM itself may add or change the case category value. If such a change is made, the application creating the confirmation must include the changed value in the Confirmation XML element that corresponds to the Filing XML element that included the original value. The Confirmation XML can then be returned to the filing application as a receipt and record of the information accepted by the court.

[3]  If values sent in Filing XML are changed, then a receiving application must return the changed values in Confirmation XML. On the other hand, if values sent in Filing XML are not changed, then a receiving application is not required to mirror all elements and return them in Confirmation XML; however, the receiving application may do so.

[4]  The following elements, which are required in Filing XML, are optional in Confirmation XML: Confirmation:Case, Confirmation:CourtDetails, Confirmation:Filers, and Confirmation:LeadDocument. Notwithstanding the rule in the paragraph above, these elements should be included in a confirmation, if the information exists. The elements are optional to accommodate situations where the information does not exist, such as when an error occurs.

[5]  There are a number of data elements that may be optionally included in Filing XML, such as Case:Category. Although it is a matter of policy, courts are encouraged not to reject filings if optional information is absent or incorrect. If the court adds or corrects this information, clerk review or EFM applications must send the added or corrected information back to the filing application in asynchronous Confirmation XML.

Dates and Times in Filing XML and Confirmation XML

[6]  The following table summarizes dates and times in Filing XML and Header XML as those dates and times relate to Confirmation 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 filedCourt's determination of when filed

[7]  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 should be edited prior to sending to reflect a date and time as close as possible to the sending date and time.

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

Confirmation:FilingStatus and Document:FilingStatus

[9]  Document:FilingStatus is the status of a document when the Confirmation:FilingStatus value is equal to Partial. Partial means that some documents in the filing may have been accepted, rejected, or are still pending review. The Document:FilingStatus element should only be used in Confirmation XML. It must be ignored in Filing XML. If Confirmation:FilingStatus is not equal to Partial, then Document:FilingStatus must be ignored by a receiving application. As with any Confirmation XML, Document:Key values must be present for all documents per this specification so that filing applications can match a filed document with the document's disposition.

Court Initiated Documents

[10]  It is possible for the receiving application to send more documents in a confirmation than the number of documents it receives. The additional documents are called court initiated documents. Court initiated documents must include a Document:Key value generated by the original receiving application (i.e., the court's application, not the filing application). Although this is a simple rule, it means that there are three types of Document:Key processing in a Confirmation XML, as follows:

KeysCourt Application ("CA")Filing Application ("FA")
Same KeysSend FA keys in Document:KeyCheck for and match FA keys in Document:Key. If each key matches, then processing is done.
Different KeysSend CA keys in Document:Key and FA keys in LegacyKeyCheck for FA keys in Document:Key. If any key is not recognized, then check for FA keys in LegacyKey. If all keys match either a Document:Key or a LegacyKey, then processing is done.
Court Initiated New KeySend CA key in Document:Key. Do not include LegacyKey.Check for FA keys in Document:Key. If any key is not recognized and FA keys does not exist in LegacyKey, then this is a court initiated document.

[11]  See the Document schema for additional documentation.

Court Initiated Transactions

[12]  Court initiated documents are distinguished from court initiated transactions. A court initiated transaction is a transaction that the court originates in a case without having first receiving a filing. Confirmation XML must not be used for court initiated transactions. Instead, Notice XML must be used for court initiated transactions.

Confirmation Acknowledgement

[13]  A confirmation acknowledgement is a confirmation 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 Confirmation XML as defined in this specification with as few elements as possible. If the transaction is successful, then the 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 sending application (i.e., the court or an intermediary server) is not responsible sending another Confirmation XML, but may do so.

1.2. Confirmation:Numbers
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Number1unbounded

[14]  Confirmation:Numbers is a container element for one or more Confirmation:Number elements. Confirmation XML may have more than one Confirmation:Number element depending on whether an intermediary application is involved in the transaction. See the Confirmation:Number element for more details.

1.3. Confirmation:Number
Data Type: xsd:string
go to top
Attribute(s)typeusefixed/default
NumberSourceNumberSourcesrequiredNone
NumberTypeNumberTypesrequiredNone
OrganizationKeyxsd:stringrequiredNone

Introduction

[15]  Confirmation:Number is a sequential number generated by a receiving application that evidences receipt of a filing. The Confirmation:Number should be generated sequentially by the receiving application and must be unique within the receiving application (taking into consideration the required attributes on the element). Delivery of a Confirmation:Number value to a sending application from a receiving application signifies that the sending application no longer has responsibility to file or re-file the filing.

[16]  The Confirmation:Number is different than the Confirmation:FilingKey. The Confirmation:FilingKey is a mirror of the Filing:Key to which the confirmation is responding.

Confirmation:Number Meaning and Responsibility to Re-File

[17]  Confirmation:Number has three required attributes (a) NumberSource (b) NumberType, and (c) OrganizationKey. The NumberSource attribute must have one of two values: Intermediary or Court. The value Intermediary means that an intermediary application has generated the confirmation number, rather than the court. The value Court means that a court has generated the confirmation number. The NumberType attribute must have one of two values: Synchronous or Asynchronous. The value Synchronous means that the communication is a synchronous confirmation. The value Asynchronous means that the communication is an asynchronous confirmation. In a synchronous transaction, regardless of whether a court or an intermediary has generated the confirmation number, the receipt of a confirmation number means that the sending application no longer has a responsibility to file or re-file the filing. If the confirmation number has been generated by an intermediary, it may be informative to the sending application (i.e., to the filer) to know whether the filing has actually reached the court. Ultimately the filer seeks confirmation that the filing reached the court. As a result, a filer will be most interested in receiving a court confirmation number and distinguishing a court and an intermediary confirmation number.

Intermediary Application: Synchronous/Asynchronous Confirmations

[18]  Assuming a filing transaction where there is a filing application, an intermediary application, and a court application, it is possible that an intermediary application will not synchronously forward a filing to a court. Instead, the intermediary application might hold the filing for a duration of time (e.g., a second, a minute, or an hour) prior to forwarding the filing to the court. In this situation, the intermediary application is only able to return a confirmation number to the filing application that has been generated by the intermediary. It cannot send a court-generated confirmation number, because no such number exists. In this situation, the intermediary application can send only one Confirmation:Number element. For example, the Confirmation:Number value might be 00000001234 with an NumberSource attribute value equal to Intermediary.

[19]  Assuming the same scenario as above, a court application could send a subsequent asynchronous confirmation through the intermediary application or directly to the filing application. If a subsequent asynchronous confirmation is sent directly from the court application to the filing application, then the Confirmation:Number value might be 00000007899 with an NumberSource attribute value equal to Court. If a subsequent asynchronous confirmation is sent through the intermediary application, then the intermediary application might only pass through the court's Confirmation XML (a discouraged practice incompatible with the Header XML specification) or it could pass through the court's confirmation number and add its own intermediary confirmation number. In the latter situation, the filing application would receive two Confirmation:Number elements and two values, such as 00000001234 and 00000007899, one with an NumberSource attribute value equal to Intermediary and another NumberSource attribute value equal to Court.

Intermediary Application: Synchronous/Synchronous Confirmations

[20]  Assuming the same three applications, the intermediary application could send the filing synchronously to the court. This would require opening a second HTTP connection between the intermediary application and the court application while the original HTTP connection between the filing application and the intermediary application is still open. This is technically possible and works well with small Filing XML, but may result in unwanted overhead and increased transaction times from the perspective of the filer for large Filing XML. In this situation, the filing application should receive two Confirmation:Number elements and two values, such as 00000001234 and 00000007899, one with an NumberSource attribute value equal to Intermediary and another NumberSource attribute value equal to Court.

Court Application: Synchronous Confirmation

[21]  If there are only two applications involved in a filing transaction, a filing application and a court application, then only one Confirmation:Number element is required. In this situation, the Confirmation:Number element must have an NumberSource attribute value equal to Court.

OrganizationKey Attribute

[22]  The OrganizationKey attribute is a required attribute that holds a unique identifier for the organization responsible for generating the confirmation number. The combination of the NumberSource attribute and the OrganizationKey attribute allows the filing application to identify the organization responsible for generating the confirmation number and whether the organization is a court or an intermediary.

1.4. Confirmation:Date
Data Type: xsd:date
go to top

[23]  Confirmation:Date is the date on which the confirmation is generated by the sending application. See the introduction to this schema's documentation or more information.

[24]  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.5. Confirmation:Time
Data Type: xsd:time
go to top

[25]  Confirmation:Time is the time at which the confirmation is generated by the sending application. See the introduction to this schema's documentation or more information.

[26]  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.6. Confirmation:FilingStatus
Data Type: FilingStatuses
go to top

Introduction

[27]  Confirmation:FilingStatus is the status of the filing. Confirmation:FilingStatus can have the following values: (a) Received, (b) Accepted, (c) Pending, (d) Rejected, (e) Held, (f) Partial, (g) Update, and (h) Error. A Confirmation:Number must be sent with all values, except for Error status.

Received

[28]  The value Received means that, at least, the receiving application has checked that the Filing XML is well-formed and valid against the schema. Receiving applications may also programmatically check whether certain values in the Filing XML are logically correct. For example, a receiving application may check to ensure that plaintiff and defendant names are acceptable values or that all fees have been paid. If the Filing XML is acceptable to the receiving application, then the receiving application must return the value Received (or other acceptable value as defined in this section) along with a Confirmation:Number. Sending the value Received with a Confirmation:Number means that the filing application no longer has a responsibility to file or re-file. The value Received will most often be used when sending a synchronous confirmation.

Accepted

[29]  The value Accepted means that the filing has been accepted by the court as filed or lodged. (It is recognized that terms such as "filed" and "lodged" and their meanings may differ among jurisdictions. Jurisdictions should define the meaning of Accepted in applicable court rules.)

[30]  The Confirmation:FilingDate and Confirmation:FilingTime are the date and time when the court accepts the filing. The Confirmation:FilingDate and Confirmation:FilingTime may be the same values as the Filing:Date and the Filing:Time in the original Filing XML, provided that the court accepts the filing application's assertion of the filing date and time. If the court does not accept the filing date and time, then it must provide its own values. The Confirmation:FilingDate and Confirmation:FilingTime values may or may not be the same as the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Accepted status. The value Accepted will most often be used when sending an asynchronous confirmation.

Pending

[31]  The value Pending means that the filing is still pending as of the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Pending status. Note that all confirmation numbers should be sequential, regardless of the Confirmation:FilingStatus (e.g., even for Pending filings). A Pending confirmation may be useful as a means of providing good customer service when a filing has been waiting in a queue for a long time. The value Pending will most often be used when sending an asynchronous confirmation.

[32]  If the value is Pending, then the Document:File element may be empty. See the Document schema for additional details.

Held

[33]  The value Held means that the filing is not only pending, but it has been reviewed and is awaiting some other action, as of the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Held status. Note that all confirmation numbers should be sequential and unique (taking into consideration the attributes on the element), regardless of the Confirmation:FilingStatus (e.g., even for Held filings). A Held confirmation may be useful as a means of providing good customer service when a filing has been waiting in a queue for a long time. The value Held will most often be used when sending an asynchronous confirmation.

[34]  If the value is Held, then the Document:File element may be empty. See the Document schema for additional details.

Rejected

[35]  The value Rejected means that the filing has been rejected by the court at a time subsequent to the initial receipt. It is, therefore, possible that a filer could receive a Confirmation:Number and a Received status, but that the document might later be rejected. Court rules should address this possibility. A Confirmation:Number must be sent with the Rejected status. A confirmation with a Confirmation:FilingStatus value equal to Rejected should also include a Confirmation:Message with a value describing the reason for the rejection. The value Rejected will most often be used when sending an asynchronous confirmation.

Partial

[36]  The value Partial means that some documents in the filing have been rejected by the court and some documents have been accepted. If the court partially rejects a filing, the status of each document can be found in the Document:FilingStatus element. Unless the Document:FilingStatus element has the value Partial, the Document:FilingStatus should not be populated and should be ignored.

Update

[37]  The value Update means that the confirmation is an updated version of a previously submitted asynchronous confirmation. The update status may not change an accepted document to rejected or a rejected document to accepted. The update status does not replace service or notice of new documents. The update status should have limited use only for sending changed data, such as party information, in situations where there has been a clerical error or other change in data that would not affect the substantive rights of parties.

[38]  If the value is Update, then the Document:File element may be empty. See the Document schema for additional details.

Error

[39]  The value Error means that there has been a technical error and the filing has not been Received. If the Filing XML is not well-formed and valid, then the receiving application must return an Error. If the value Error is used, then a Confirmation:Number must not be sent.

[40]  If the errors in the Filing XML or the network connection are so severe that the receiving application cannot respond with a confirmation (e.g., the receiving application has no knowledge of the filing), then the filing application should generate Confirmation XML itself with a Confirmation:FilingStatus value equal to Error. A filing application should generate a confirmation, for example, if it cannot reach the server to create an HTTP connection, if the HTTP connection times out, or if the HTTP response does not return a well-formed and valid confirmation. It may also happen that the filer's network connection is not working, in which case the filing application should generate a confirmation. A confirmation with a Confirmation:FilingStatus value equal to Error should also include a Confirmation:Error element with a values describing the error.

1.7. Confirmation:FilingDate
Data Type: xsd:date
go to top

[41]  Confirmation:FilingDate is the date of the filing as confirmed by the court. 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. Otherwise, Confirmation:FilingDate is a date designated by the court. The Confirmation:FilingDate is not the same as the transmission date, although these date values may be the same or very close in time. Confirmation:FilingDate is not a date from the document. Confirmation:FilingDate is not the date of service of process. See the introduction to this schema's documentation or more information.

[42]  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.8. Confirmation:FilingTime
Data Type: xsd:time
go to top

[43]  Confirmation:FilingTime is the time of the filing as confirmed by the court. 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. Otherwise, Confirmation:FilingTime is a time designated by the court. The Confirmation:FilingTime is not the same as the transmission time, although these time values may be the same or very close in time. See the introduction to this schema's documentation or more information.

[44]  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.9. Confirmation:LegacyCases
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
LegacyCase1unbounded

[45]  Confirmation:LegacyCases is a container element for the Confirmation:LegacyCase element.

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

[46]  Confirmation:Filers is a container element for one or more Confirmation:Filer elements.

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

[47]  Confirmation:Filer contains information about who filed the case as accepted by the court. This information should mirror the information accepted by the court. See Person and Organization schemas.

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

[48]  Confirmation:People is a container element for one or more Confirmation:Person elements. Confirmation:People should include information about people sent in the Filing XML as accepted by the court. Confirmation:People should also include people added to the case by the court in the context of the filing transaction. Confirmation:People should not include people that are in the case management system, but are otherwise unrelated to the filing. See Person schema.

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

[49]  Confirmation:Organizations is a container element for one or more Confirmation:Organization elements. Confirmation:Organizations should include information about organizations sent in the Filing XML as accepted by the court. Confirmation:Organizations should also include organizations added to the case by the court in the context of the filing transaction. Confirmation:Organizations should not include organizations that are in the case management system, but are otherwise unrelated to the filing. See Organization schema.

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

[50]  Confirmation:Things is a container element for one or more Confirmation:Thing elements. Confirmation:Things should include information about things sent in the Filing XML as accepted by the court. Confirmation:Things should also include things added to the case by the court in the context of the filing transaction. Confirmation:Things should not include things that are in the case management system, but are otherwise unrelated to the filing. See Thing Schema.

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

[51]  Confirmation:Charges is a container element for one or more Confirmation:Charge elements. Confirmation:Charges should include information about charges sent in the Filing XML as accepted by the court. Confirmation:Charges should also include charges added to the case by the court in the context of the filing transaction. Confirmation:Charges should not include charges that are in the case management system, but are otherwise unrelated to the filing. See Charge schema.

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

[52]  Confirmation:LeadDocuments is a container element for Confirmation:LeadDocument. Confirmation:LeadDocuments should include lead documents added to the case by the court. Regardless of whether the filing application sends a base64-encoded document or a link, there is no requirement to send back a base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See Document schema.

[53]  It is possible that a filer or a filing application identifies what should be an attachment as a lead document. In this situation, the clerk review application should allow the clerk to reclassify the lead document as an attachment. Likewise, the clerk review application should allow the clerk to reclassify an attachment as a lead document. The Confirmation XML must include a lead document, in any situation. All documents, whether a lead document or an attachment, must be identified using a unique Document:Key value. If documents switch nodes or are included in Confirmation XML nodes that are in a different order than Filing XML nodes, then the unique Document:Key value must must follow the document. See the Document schema and the Document:Key element for more information.

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

[54]  Confirmation:Attachments is a container element for one or more Confirmation:Attachment elements. The Confirmation:Attachments element should include attachments added to the case by the court. Regardless of whether the filing application sent a base64-encoded document or a link, there is no requirement to send back the base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See the Confirmation:LeadDocument element for documentation on switching a lead document and confirmation or changing the order of of attachments. See the Document schema and the Document:Key element for more information.

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

Attribute(s)typeusefixed/default
FeeTotalxsd:stringrequiredNone

[55]  Confirmation:Fees is a container element for one or more Confirmation:Fee elements. Confirmation:Fees must include each individual fee charged to the filer by 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 Fee schema.

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

[56]  Confirmation:Services is a container element for one or more Confirmation:Service elements. A Confirmation:Service element represents one service of process event. To express more than one service of process event, applications must use more than one Confirmation:Service elements. See Confirmation:Service element.

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

[57]  Confirmation:Calendars is a container element for one or more Confirmation:Calendar elements. A Confirmation: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 Confirmation:Calendar element. To express multiple days, applications must use multiple Confirmation:Calendar elements. To express events taking place in different departments, applications must also use multiple Confirmation:Calendar elements. See Confirmation:Calendar element.

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

[58]  Confirmation:Extensions is a container element for one or more Confirmation:Extension elements. In a filing, a Filing:Extension is a generic name/value pair that allows filing 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 Extension schema.

1.22. Confirmation:Confidential
Data Type: xsd:boolean
go to top

[59]  Confirmation:Confidential is a single element of type boolean. When set to true, Confirmation:Confidential means that the court has honored the filer's request to keep the incoming filing confidential. When set to false, Confirmation:Confidential means that the court has not honored the filer's request.

1.23. Confirmation:Sealed
Data Type: xsd:boolean
go to top

[60]  Confirmation:Sealed is a single element of type boolean. When set to true, Confirmation:Sealed means that the court has honored the filer's request to seal the document. When set to false, Confirmation:Sealed means that the court has not honored the filer's request.

1.24. Confirmation:Messages
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Message1unbounded

[61]  The Confirmation:Messages element is a container element for one or more Confirmation:Message elements.

1.25. Confirmation:RunMode
Data Type: RunModes
go to top

[62]  Confirmation: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 programmatically, rather than deleted manually. Confirmation:RunMode must mirror the value sent in the original filing.

[63]  Applications are urged to implement Confirmation: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.26. Confirmation:Errors
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Error1unbounded

[64]  The Confirmation:Errors element is a container element for one or more Confirmation:Error elements.

1.27. Confirmation:Message
Data Type: Message:Message
go to top

[65]  Confirmation:Message is descriptive text about the confirmation or some other message from the court to the filer. Confirmation:Message must be used when Confirmation:FilingStatus value is equal to Rejected. Confirmation:Message may be used for other messages intended to be conveyed to the filer, except for error messages.

[66]  The corresponding Filing:Message element is defined as a message intended to be conveyed to the court from the filer on any topic. Unlike other confirmation elements, Confirmation:Message should not mirror the text sent by the filing application. Instead, the Confirmation:Message should include a message intended to be conveyed from the court to the filer, if any.

[67]  Applications must use the Error:Message element when sending an error message.

1.28. Confirmation:FilingKey
Data Type: Key:Key
go to top

[68]  Confirmation:FilingKey is the value of the Filing:Key in the original filing. Receiving applications must send the original Filing:Key with the confirmation so the filing application can match the original filing with the confirmation.

1.29. Confirmation:Case
Data Type: Case:Case
go to top

[69]  Confirmation:Case contains information about the case filed as confirmed by the court. If the court adds, deletes, or changes information in the Filing:Case element, then receiving application must send back the added or changed information and must not send back the deleted information. See Case Schema.

1.30. Confirmation:LegacyCase
Data Type: Case:Case
go to top

[70]  Confirmation:LegacyCase contains information about a case with a case number that is associated with, and a predecessor of, Confirmation:Case. See Case Schema.

1.31. Confirmation:CourtDetails
Data Type: CourtDetails:CourtDetails
go to top

[71]  Confirmation:CourtDetails contains information about the court into which documents have been filed as confirmed by the court. Filing applications should copy this information from the court's Policy XML. As a result, this information should not change in Confirmation XML. See CourtDetails Schema.

1.32. Confirmation:Person
Data Type: Person:Person
go to top

[72]  Confirmation:Person contains information about a person that is a party to a case or is otherwise associated with a case. If the court adds, deletes, or changes information in the Filing:Person element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:People documentation. See Person schema.

1.33. Confirmation:Organization
Data Type: Organization:Organization
go to top

[73]  Confirmation:Organization contains information about a organization that is a party to a case or is otherwise associated with a case. If the court adds, deletes, or changes information in the Filing:Organization element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:Organizations documentation. See Organization schema.

1.34. Confirmation:Thing
Data Type: Thing:Thing
go to top

[74]  Confirmation:Thing contains information about a thing associated with a case. If the court adds, deletes, or changes information in the Filing:Thing element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:Things documentation. See Thing Schema.

1.35. Confirmation:Charge
Data Type: Charge:Charge
go to top

[75]  Confirmation:Charge contains information about a charge. If the court adds, deletes, or changes information in the Filing:Charge element, then receiving application must send back the added or changed information and must not send back the deleted information. See the Confirmation:Charges documentation. See Charge Schema.

1.36. Confirmation:Fee
Data Type: Fee:Fee
go to top

[76]  Confirmation:Fee contains information about a court filing fee. See Confirmation:Fees documentation, the Fee schema, and the Policy XML specification.

1.37. Confirmation:Service
Data Type: Service:Service
go to top

[77]  Confirmation:Service contains information about documents that have been processed served. See the Service schema.

1.38. Confirmation:Coversheet
Data Type: Document:Document
go to top

[78]  Confirmation:Coversheet contains a filing coversheet document, if any, as accepted by the court. Regardless of whether the filing application sent a base64-encoded document or a link, there is no requirement to send back the base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See the Document schema.

1.39. Confirmation:LeadDocument
Data Type: Document:Document
go to top

[79]  Confirmation:LeadDocument is the primary and most important document in a filing as accepted by the court. See the Confirmation:LeadDocuments documentation and the Document schema.

1.40. Confirmation:Attachment
Data Type: Document:Document
go to top

[80]  Confirmation:Attachment contains information about a related documents as accepted by the court. See the Confirmation:LeadDocument and Confirmation:Attachments elements.

1.41. Confirmation:Payment
Data Type: Payment:Payment
go to top

[81]  A Confirmation:Payment provides confirmation information about a payment made by a filer. In a Confirmation:Payment only the Payment:Total should be included as confirmation of the total amount charged to the filer's credit card. In a confirmation, this amount should match the amount in the Confirmation:Fees element FeeTotal attribute. See the Payment schema.

1.42. Confirmation:Calendar
Data Type: Calendar:Calendar
go to top

[82]  A Confirmation:Calendar provides confirmation information about calendared events. See the Calendar schema.

1.43. Confirmation:Extension
Data Type: Extension:Extension
go to top

[83]  A Confirmation:Extension is a generic name/value pair that allows applications to send information not included in the confirmation specification. See Confirmation:Extensions element.

1.44. Confirmation:Error
Data Type: Error:Error
go to top

[84]  A Confirmation:Error contains human- and machine-readable information about an error in the Filing XML. If the Confirmation:Number element is not returned, then a Confirmation:Error must be returned. If Confirmation:FilingStatus is equal to Error, then the Confirmation:Error must be returned.

2. Simple Types

2.1. FilingStatuses
Data Type: xsd:string
go to top
Enumeration(s)

Value
Received
Accepted
Pending
Held
Rejected
Partial
Update
Error
2.2. RunModes
Data Type: xsd:string
go to top
Enumeration(s)

Value
Test
Live
2.3. NumberSources
Data Type: xsd:string
go to top
Enumeration(s)

Value
Court
Intermediary
2.4. NumberTypes
Data Type: xsd:string
go to top
Enumeration(s)

Value
Synchronous
Asynchronous

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. Error
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Error/03/
  
3.4. Extension
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Extension/03/
  
3.5. Fee
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Fee/03/
  
3.6. Key
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Key/03/
  
3.7. Organization
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Organization/03/
  
3.8. Person
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Person/03/
  
3.9. Thing
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Thing/03/
  
3.10. Calendar
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Calendar/01/
  
3.11. Case
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Case/01/
  
3.12. Charge
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Charge/01/
  
3.13. Document
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Document/01/
  
3.14. Message
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Message/01/
  
3.15. Payment
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Payment/01/
  
3.16. Service
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Service/01/
  

4. Change History

4.1. 2003-01-15
Editor: Winchel Vincent
go to top

Initial Draft.

4.2. 2003-07-21
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.0.9.

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

Copied.

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

Copied.

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

Added new Payment and Calendar Schemas.

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

Normalized using xmlLegal Normalizer 0.0.9. Deleted Date.xsd and Time.xsd. Changed Key, CourtDetails, and Extension namespaces and import locations to reflect move of schema to Building Block folder.

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

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

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

Copied.

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

Changed documentation. Added clarifications and examples for Confirmation:Number and Confirmation:FilingStatus. Added additional explanation to Confirmation:FilingKey. Made typographical changes.

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

Copied.

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

Changed Confirmation:ErrorMessage to Confirmation:Message. Changed documentation to state that Confirmation:ErrorMessage can be used as an error message and as a descriptive message for why a rejection occurred. Moved order of Confirmation:Message to correspond to new Filing:Message. Made Confirmation:Message a Memo simpleType. Added Memo simpleType. Added new Confirmation:LegacyCases and Confirmation:LegacyCase. For readability purposes, rearranged the order of Fees and Service so that Fees would exist next to Payment and so that Service information would exist lower.

4.12. 2004-04-29
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.1.0.

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

Copied.

4.14. 2004-08-03
Editor: Winchel Vincent
go to top

Added Partial to FilingStatuses to support partial acceptance and rejection. Changed primitive schemas namespace versions from 01 to 02.

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

Normalized using xmlLegal Normalizer 0.1.0.

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

Copied.

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

Copied. Added structured Error Schema and new Error element. Added Confirmation:Sealed. Added Confirmation:Services. Added Confirmation:Calendars. Added TotalFees attribute to Confirmation:Fees element.

4.18. 2005-07-12
Editor: Winchel Vincent
go to top

Added Confirmation:Numbers element. Added Applications and OrganizationKey attributes to Confirmation:Number element. Documentation.

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

Copied.

4.20. 2008-09-30
Editor: Schema Generator
go to top

Normalized using xmlSchemaGenerator Normalizer 0.1.5.

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

Copied. Added attributes to Case:Number element. Added Held and Update values to FilingStatuses enumerated list. Added new Message schema and made Confirmation:Message of type Message. Removed Memo simpleType.

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