Introduction[1] 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. [2] 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. [3] Notice XML includes an ancillary specification named Notice List XML that is not part of the Filing XML specification. [4] As a general rule, unless this document specifies otherwise, the rules for Notice XML and confirmations to Notice XML are the same as the rules for Filing XML and confirmations to Filing XML. This documentation includes special rules for Notice XML and common rules that apply to both Filing XML and Notice XML. Envelope XML and Header XML[5] Notice XML uses Envelope XML and Header XML in the same way as Filing XML. See the Envelope schema, the Header schema, and the Filing schema for more information. Envelope and Transmission Protocols[6] It is logically possible to transmit Filing XML, Confirmation XML, and Notice XML by HTTP, HTTPS, FTP, SMTP, facsimile, postal mail, and bar coded paper (fax or post). The recommended approach is to use HTTP and HTTPS as the transmission protocol for electronic filings and notices. It is possible, however, that some parties in a case that are entitled to notice do not have an HTTP address to which a notice can be transmitted. In such situations, notices should be converted to paper or facsimile and transmitted using traditional methods. Pre-Case Notice and Existing-Case Notice[7] 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. [8] In the context of a notice, there is a distinction between a pre-case notice and an existing-case notice. A pre-case notice is a notice about a matter that is sent prior to the existence of a case number assigned by a court. An existing-case notice is a notice sent after a court has created a case and assigned a case number. Synchronous and Asynchronous Confirmations[9] An application that receives Notice XML over HTTP must send a synchronous confirmation using Confirmation XML to the sending application. There is, however, no requirement for a receiving application to send asynchronous confirmations to Notice XML. Elements of a Notice[10] The Notice element is the intended root element of the schema. [11] Notice must contain one of each of the following elements: Notice:Key, Notice:Date, Notice:Time, Notice:Filers, and Notice:RunMode. [12] Notice 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 Notice:LeadDocument and the Document schema for more information. [13] Notice may contain Notice:Case, Notice:CourtDetails, Notice:LegacyCases, Notice:People, Notice:Organizations, Notice:Things, Notice:Charges, Notice:Coversheet, Notice:Attachments, Notice:Fees, Notice:Payment, Notice:Services, Notice:Calendars, Notice:Extensions, Notice:Confidential, Notice:Sealed, and Notice:Message.
[14] Notice:Date is the sender's assertion of the date of the notice. The Notice:Date is not the same as the transmission date, although these date values should be the same or very close in time. Notice:Date is not a date from the transmitted document. [15] Notice:Time is the sender's assertion of the time of the notice. The Notice:Time is not the same as the transmission time, although these time values should be the same or very close in time. Child Element(s) | minOccurs | maxOccurs | LegacyCase | 1 | unbounded |
[16] Notice:LegacyCases is a container element for one or more Notice:LegacyCase elements. Child Element(s) | minOccurs | maxOccurs | Filer | 1 | unbounded |
[17] Notice:Filers is a container element for one or more Notice:Filer elements. The term filer and sender are synonymous. The sender's information must not be duplicated in Notice:People or Notice:Organizations.
[18] Notice:Filer contains information about who sent the notice. Notice: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. [19] Specific courts and jurisdictions should define business rules for this element. There are a number of options for the meaning: (a) Notice:Filer could be the exact person who sends the notice, such as a legal secretary or a lawyer, (b) Notice: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) Notice: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) Notice:Filer could be the party on whose behalf a lawyer or law firm files a document. [20] The Person and Role schemas can be used to assign additional roles to the sender (such as Attorney, Plaintiff, or Defendant) and associate senders and other people and organizations. As a result, the sender does not need to be, and must not be, duplicated in the Filer:Person or Filer:Organization elements. Child Element(s) | minOccurs | maxOccurs | Person | 1 | unbounded |
[21] Notice:People is a container element for one or more Notice:Person elements. Notice:People may contain people, whether parties, officials, or judges, associated with the case or matter. This information is not required for notices, but may be sent at the discretion of the sender.
[22] Notice:Organizations is a container element for one or more Notice:Organization elements. Notice:Organizations may contact the organizations, whether parties, state agencies, or others, associated with the case or matter. This information is not required for notices, but may be sent at the discretion of the sender. Child Element(s) | minOccurs | maxOccurs | Thing | 1 | unbounded |
[23] Notice:Things is a container element for one or more Notice:Thing elements. A Notice:Thing is an animal or inanimate object (i.e., not a legal entity) that is a party or potential party to a case. This information is not required for notices, but may be sent at the discretion of the sender. Child Element(s) | minOccurs | maxOccurs | Charge | 1 | unbounded |
[24] Notice:Charges is a container element for one or more Notice:Charge elements. A Notice:Charge is the details of an offense or complaint in a criminal, juvenile, or other criminal-like case. Notice:Charge will not usually be used in civil cases. This information is not required for notices, but may be sent at the discretion of the sender. See the Charge schema.
[25] Notice:LeadDocuments is a container element for one or more Notice:LeadDocument elements. A Notice:LeadDocument is the primary and most important document in a notice. A notice may contain several Notice:LeadDocument elements; however, it may contain only one logical lead document. The purpose of allowing multiple Notice:LeadDocument elements is to allow one logical lead document to be simultaneously sent in different electronic document formats, such as Adobe PDF and Microsoft Word. For example, a sender might submit Interrogatories as both a Microsoft Word document and as an Adobe PDF document, so that the receiver has both an editable version and a static version of the document. See the Notice:LeadDocument element. Child Element(s) | minOccurs | maxOccurs | Attachment | 1 | unbounded |
[26] Notice:Attachments is a container element for one or more Notice:Attachment elements. A Notice:Attachment is a secondary document, as described in Notice:LeadDocument. Other than its meaning, Notice:Attachment works in the same way as Notice:LeadDocument, except that Notice:Attachment can and should have different Document:Key values. See Notice:LeadDocument and Document schema. Child Element(s) | minOccurs | maxOccurs | Fee | 1 | unbounded |
Attribute(s) | type | use | fixed/default | FeeTotal | xsd:string | required | None |
[27] Notice:Fees is a container element for one or more Notice:Fee elements. Notice:Fees must include each individual fee submitted by the sender to a service provider. The total amount of the fees, whether there is only one fee or multiple fees, must be included in the required attribute FeeTotal. This information is required in a notice, only if a service provider is associated with delivering the notice and only if the service provider charges a fee for delivery services. Service providers may use Policy XML to publish fees. See the Fee schema. Child Element(s) | minOccurs | maxOccurs | Service | 1 | unbounded |
[28] Notice:Services is a container element for one or more Notice:Service elements. A Notice:Service element represents one service of process event. To express more than one service of process event, applications must use more than one Notice:Service elements. See Notice:Service element. Child Element(s) | minOccurs | maxOccurs | Calendar | 1 | unbounded |
[29] Notice:Calendars is a container element for one or more Notice:Calendar elements. A Notice:Calendar element represents multiple calendar events on a single day for a given organization. To express multiple calendar events on a single day for a single organization, applications must use only one Notice:Calendar element. To express multiple days, applications must use multiple Notice:Calendar elements. To express events taking place in different organizations, applications must also use multiple Notice:Calendar elements. See Notice:Calendar element. Child Element(s) | minOccurs | maxOccurs | Extension | 1 | unbounded |
[30] Notice:Extensions is a container element for one or more Notice:Extension elements. A Notice:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. The Notice: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. [31] Notice:Confidential is an optional element of type boolean. When set to true, Notice:Confidential means that the sender wishes the communication to remain confidential. [32] If the Notice:Confidential element value is equal to true, then all documents in a filing are requested to be confidential. As a result, if the Notice:Confidential element value is equal to true, then the Document:Confidential element must be absent or it must be ignored, if present. [33] Notice:Sealed is an optional element of type boolean. When set to true, Notice:Sealed means that the sender wishes the communication to be part of settlement discussions. Notice:Sealed is distinguished from Notice:Confidential in that Notice:Confidential is merely a sender's request to keep the communication confidential, whereas Notice:Sealed is a sender's request to associate the documents with settlement discussions. Generally, information from settlement discussions may not be used in other aspects of litigation. This element provides a means of distinguishing this type of information. [34] If the Notice:Sealed element value is equal to true, then all documents in a filing are requested to be part of settlement discussions. As a result, if the Notice:Sealed element value is equal to true, then the Document:Sealed element must be absent or it must be ignored, if present.
[35] To be done. [36] To be done. [37] To be done. [38] Notice:RunMode is a single element with two possible values: Test or Live. Notice:RunMode is used when sending test notices to a live server so that downstream applications will know to ignore or behave differently toward the test notice. The element may also be useful in situations where test notices into a live server need to be purged mechanically, rather than deleted manually. [39] Applications are urged to implement Notice: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 notices and confirmations in a live system, while retaining the ability to identify a notice or a confirmation as a test. The ability to send and receive test notices and confirmations in a live system is helpful in the final stages of going live with an electronic filing system. [40] Notice:Message is a message intended to be conveyed to the receiver from the sender on any topic. [41] Notice:Key is a unique identifier for the notice. See the Key schema. [42] Notice:Case contains information about the case being sent. This information must be sent for existing-case notices using the Case:Existing element. This information should be sent for pre-case notices using the Case:New element. See the Case schema. [43] Notice:LegacyCase contains information about a case or a matter with a case number that is associated with, and a predecessor of, Notice:Case. For example, if a case is appealed, then the original case information can be included in Notice:LegacyCase when sending documents for a new case. See the Case schema. [44] Notice:CourtDetails contains information about the court associated with a case or matter. If a matter is associated with a court, then this information is required. If a matter is not associated with a case, then this information is not required. Sending applications should copy this information from the court's Policy XML. See the CourtDetails schema. [45] Notice:Person contains information about a person that is a party to a case or is otherwise associated with a case or a matter. See Notice:People documentation. See the Person schema. [46] Notice:Organization contains information about an organization that is a party to a case or is otherwise associated with a case or a matter. See Notice:Organizations documentation. See the Organization schema. [47] Notice:Thing contains information about a thing that is a party to a case or a potential party to a case. See Notice:Things documentation. See the Thing schema. [48] Notice:Charge contains information about a charge or a potential charge. See Notice:Charges documentation. See the Charge schema. [49] Notice:Fee contains information about a fee charged by a service provider to deliver a notice. Sending applications should copy this information from the service provider's Policy XML. See the Notice:Fees element, the Fee schema and the Policy XML specification. [50] Notice:Service contains information about documents for which service of process has taken place. See the service Schema. [51] Notice:Coversheet contains a coversheet document, such as a cover letter, if any. Notice:Coversheet is not a lead document and is not an attachment. See the Filing:Coversheet element. [52] Notice:LeadDocument is the primary and most important document in a notice. For example, if a party is sending a Demand Letter supported by an Affidavit and two Exhibits, then the Demand Letter would be the lead document and the other three documents would be attachments. See the Filing:LeadDocument element and the Document schema. [53] Notice:Attachment contains information about a secondary document. See the Notice:LeadDocument, Filing:LeadDocument, Notice:Attachments, and Filing:Attachments element. [54] A Notice:Payment provides information about a sender's credit card so that a sender can pay a service provider for delivering a notice. See the Payment schema. [55] A Notice:Calendar provides information about calendared events. In the context of a notice, the Calendar schema can be used to convey an event scheduled by a court or an event proposed to be scheduled by a law firm. For example, a firm might send another firm a Notice of Deposition with a proposed date and time for the deposition. See the Calendar schema. [56] A Notice:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. See the Notice:Extensions element. |