Introduction[1] Document elements can be grouped generally into two categories: (a) elements that contain metadata about a document and (b) elements that either reference or include a document. Referencing a document is done using links, while including a document is done by base64-encoding the document. The following sections provide information about using links and base64-encoding and outlines advantages and disadvantages of both approaches. General Rules[2] This section outlines general rules about links and base64-encoding. [3] (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. [4] (b) Base64-encoding is generally simpler than links. Links is more complicated. [5] (c) Links performs better than base64-encoding. Links is better for transmitting large documents and filings (over 250-500 KB). [6] (d) Sending and receiving applications are encouraged to implement and support both approaches. Base64-Encoding Process[7] Base64-encoding is done by encoding the binary representation of an electronic file in printable ASCII characters. Unlike some text encodings, base64-encoding does not include any XML special characters in its ASCII representation, such as < or >. The only characters used are the upper- and lower-case Roman alphabet characters (A-Z, a-z), the numerals (0-9), and the + and / symbols, with the = symbol as a special suffix code. As a result, base64 ASCII is 'XML-safe.' [8] Base64-encoding is defined by IETF RFC 1421 and RFC 2045. There are a number of free and commercial software components that will encode a binary file in base64 ASCII and decode in reverse. Using a component, converting to base64 is usually as simple as loading the file from a given path and calling an encode property. The base64 ASCII is then available from the component to insert into an XML node (in this case, Document:File or Document:DataFile), usually through DOM or some other XML writer. After the sending application sends the XML to a receiving application, decoding is done by reading the XML node, loading the ASCII text into a base64 component, calling a decode property, and then saving the resulting binary representation as a file using the component. (This is perhaps 5-10 lines of code for each application, sending and receiving.) Links Process[9] Using links is done first by posting an electronic file to a web server so that it is available via HTTP. (It is possible to use a link to a local directory system, but the local directory system must be available to both the sending and receiving applications, something that is usually not the case with electronic filing to and from different organizations.) The sending application then inserts the document's HTTP address into an XML node (in this case, Document:File or Document:DataFile) and sends the XML to a receiving application over an HTTP connection. The receiving application has two choices in how to process the incoming XML and the links within it. The receiving application can either (a) validate the XML, discover the link(s), immediately download the file(s), and then send an HTTP response (pre-confirmation download) or (b) validate the XML, save the XML, send an HTTP response, and then discover the link(s) and download the file(s) (post-confirmation download). [10] In either case, to obtain the electronic file, the receiving application must initiate a subsequent HTTP download from a remote HTTP location. If the resource(s) at the remote HTTP location is password protected, then the receiving application must obtain a username and password to accomplish the subsequent download. Simplicity[11] Generally, base64-encoding is simpler to use than links. Base64-encoding allows a filing application to create an XML document that is complete and that must be transferred once, over one HTTP connection. The base64-encoded document is contained within one Filing XML file, rather than separated from it, which is less complicated than managing several files. Links break, whereas the base64-encoded ASCII is always available in the Filing XML. [12] Links requires at least two HTTP connections -- one connection for transmitting the Filing XML and another for downloading the document. For each document in the Filing XML (there may be several documents within one filing), an additional HTTP connection is required to download the document. Each connection runs the risk of being broken. It is also possible that the HTTP resource is unavailable when the second connection is attempted. Further, if the document(s) are deemed sensitive and are password protected, then there is an additional layer of security and complexity in between the receiving application and the document(s). Filing and Document Size, Transaction Speed, and Performance[13] While base64-encoding is simpler, it is slow and cumbersome for large filings and large documents. Base64-encoding increases the size of a binary file by 33%. A Filing XML that includes a base64 encoded document will be larger than the binary document itself. This has an impact on both transaction speed when a sending application delivers Filing XML and when a receiving application processes the Filing XML. [14] With respect to transaction speed, when transmitting from a sending application to a receiving application over the Internet, links is much quicker. The size of a typical Filing XML using links is about 20 KB. In contrast, a Filing XML with two base64 encoded PDF documents (each approximately five page) is around 200 KB. If documents are downloaded from links after an HTTP confirmation is returned by the receiving application (post-confirmation download), then the transaction time a measured in a second or fractions of seconds. If base64-encoding is used, then the transaction time is measured in a few seconds for small filings (e.g., under 250 KB) but in several seconds or minutes for large filings (500 KB and over). Even if documents are downloaded prior to sending an HTTP confirmation (pre-confirmation download), the transaction time is around 50% faster using links (in comparison to base64-encoding where the synchronous confirmation includes the base64 encoded document). If documents are downloaded after sending an HTTP confirmation (post-confirmation download), then the size of the documents is irrelevant to the transaction speed and the transaction time is always measured in seconds or fractions of seconds. [15] With respect to processing Filing XML, if DOM is used, then loading Filing XML with base64-encoded documents into DOM is slower than loading Filing XML with links only. All DOM implementations can easily handle a 20 KB file and perform well. Some DOM implementations would have performance problems when loading XML over 2.5 MB. (This is based on past testing that may be outdated. It is provided as a general guideline only.) [16] Large files will cause performance problems in any implementation. Links provides better performance than base64-encoding. Base64-encoding, however, is suitable in filing systems where the total size of the Filing XML will remain under 250-500 KB. Document Confidentiality[17] Some electronically filed documents may be not suitable for open publication on the Internet. If this is the case, then documents published on the Internet for HTTP download using links must be password protected. This is an issue when using links, but is not an issue when using base64-encoding. Although it is not difficult to restrict access to an HTTP resource, doing so adds an additional layer of complexity to the electronic filing system. Specification[18] Document is the intended root element of the schema. Document includes two required elements (a) Document:Key and (b) Document:File. The Document:Key element is a unique identifier for the document. The Document:File element is the document itself or a link to the document. All other elements are optional. Draft Documents[19] The Document element includes an optional attribute Draft. The Draft attribute has a default value equal to false. If the Draft attribute is not present or set to false, then this means the document is intended as a complete and final document to be filed into the court. If the Draft attribute is set to true, then this means the document is submitted to the court as a draft document. Usually, in the draft document situation, the court must edit the document or take some action on it prior to finalizing the document for filing. For example, a Summons would be filed as a draft. Likewise, a Proposed Order would be filed as a draft.
[20] Policy XML includes an element Policy:AcceptedMIMETypes that contains an element Policy:MIMEType. The Policy:MIMEType element includes an attribute DocumentVersions. The DocumentVersions attribute can have three possible values, one of which is Draft. The value Draft means that the specified MIME type can be used for draft documents filed with the court. For example, a court might require Adobe PDF documents for final documents, but Microsoft Word documents for draft documents. Filing applications should consult a court's Policy XML to determine the MIME types acceptable for draft documents. Attachments and Exhibits[21] The attributes Exhibit and PrimaryDocumentKey are used to designate a document as an exhibit of another document, rather than an additional attachment to an electronic filing. If the Exhibit attribute is set to true, then the document is an exhibit. If the Exhibit attribute is absent or set to false, then the document is an attachment. The PrimaryDocumentKey attribute is used to associate the document with the Document:Key value of another document within the same filing. The PrimaryDocumentKey attribute may not refer to a Document:Key in the same logical document. Attribute(s) | type | use | fixed/default | LegacyKey | xsd:string | optional | None |
Unique Document Identifier[22] Document:Key is a unique identifier for a document. The identifier must be unique to a logical document (e.g., to a Complaint for Child Support). There may, however, be more than one electronic file in the filing that represents the same logical document. As a result, there is no requirement for the Document:Key value be unique within the filing. One Logical Document In Two File Formats[23] It is possible for a filing application to send the same logical document in a filing, but to send it in more than one electronic formats, such as Adobe PDF, TIFF, or Microsoft Word. This is accomplished in the same filing by creating multiple Document elements with the same Document:Key value. If there are multiple Filing:LeadDocument elements, for example, then for each Filing:LeadDocument element, there would be a Document:Key element with the same unique identifier as a value. [24] If one logical document is sent in more than one file format, then the Document:Key elements with the same values must be children of the same type of parent node, such as Filing:LeadDocument or Filing:Attachment. Applications must not use the same Document:Key value in, for example, a Filing:LeadDocument and a Filing:Attachment. If two duplicate Document:Keys values are used, then the Document:MIMEType values must be different. For example, the filing application may send two of the same Complaint for Child Support documents, but the file formats must be different (e.g., Microsoft Word and Adobe PDF). One Document and One Data File[25] Sending one logical document in two file formats is distinguished from sending one logical document and a data file associated with the document. When sending a document and an associated data file, one Document:Key element and value must be used along with a Document:File element and a Document:DataFile element. A typical scenario would be when a document generation system merges a data file into a document template to create a finished document prior to filing. In this scenario, it is often easier for the receiving application to receive both the finished document and the original data file used to do the merge, since the information may be easier to parse from the data file than it is from the finished document. For example, if the Document:File contains an Adobe PDF document, then the Document:DataFile may contain an XML document. [26] If the data file in a Document:DataFile element is based on an XML Schema, then the Namespace attribute on the Document:DataFile element must be populated with the namespace of the XML Schema. One Data File[27] Sending one document and one data file is distinguished from sending a data file without a document. One means of extending the Filing XML specification to accommodate additional data elements is to define a new schema with new data elements and then send a corresponding XML instance as if it were a document. The data file can then be extracted from the Filing XML as any other document would be and the data used by the receiving application. [28] The following processing rules must be followed to send a data file without a document: (a) the data file must be located in the Document:File element (not the Document:DataFile element), (b) the Document:GenericType must be populated with the value Data File, (c) if the data file is based on an XML Schema, then the Namespace attribute on the Document:File element must be populated with the namespace of the XML Schema, and (d) the Document:Type may be populated with a value describing the type of data file. Document Identifiers in Confirmations[29] A filing application must include a unique Document:Key for every logical document in a Filing XML. The filing application requires the Document:Key in Confirmation XML, so it can match the confirmed document with the filed document to determine the filed document's disposition. The filing application generates its unique identifier based on the filing application's internal rules. The receiving application may have its own method of generating unique document identifiers and may wish, as a result, to substitute its unique identifier for the identifier provided by the filing application. This causes a potential conflict that is resolved by the Document:Key attribute LegacyKey and the following processing rules. [30] If the receiving application wishes to use the filing application's Document:Key value as a unique identifier, then the receiving application may do so. If the receiving application uses the filing application's unique identifier, then the receiving application must send the filing application's Document:Key value in a Confirmation XML Document:Key element along with the disposed document in a corresponding Document:File element. [31] On the other hand, if the receiving application wishes to use its own unique identifier, then the receiving application must send its unique identifier in a Confirmation XML Document:Key element and must send the filing application's unique identifier in the LegacyKey attribute. In this situation, the receiving application's unique identifier will be the value used to identify the document in future transactions (such as Request-Response transactions). It is the responsibility of the filing application to match and track the filing application's unique identifier and the receiving application's unique identifier. The receiving application is responsible only for tracking its own unique identifier. Court Initiated Documents[32] 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: Keys | Court Application ("CA") | Filing Application ("FA") |
---|
Same Keys | Send FA keys in Document:Key | Check for and match FA keys in Document:Key. If each key matches, then processing is done. | Different Keys | Send CA keys in Document:Key and FA keys in LegacyKey | Check 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 Key | Send 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. |
Identifying Draft Documents[33] These processing rules must be used for both final and draft documents. It is possible that a draft document sent in Filing XML will be returned in Confirmation XML as a final document. This is not considered a court initiated document. Even if a draft document changes to a final document, the original Document:Key value must be included either in a confirmation's Document:Key element or in the LegacyKey attribute. If this rule is not followed, then the filing application has no means of matching the filed draft document with the confirmed final document. [34] Document:Title is the title of the document as it appears on the face of the document. A document's title is sometimes confused with a document's type. Many developers confuse Document:Title with the electronic document's computer filename. Document:Title is not the same as Document:Type or the document's filename. [35] It is difficult, sometimes impossible, to parse the Document:Title value from an electronic image or from other unstructured document formats without looking at the face of the document. Accordingly, it is suggested that applications provide a user interface for the user to type the Document:Title manually or some other means to extract the exact title from the document. See Document:Type. [36] Attorneys sometimes write long and varied document titles on the face of a document. A simple document title for a common document might be Civil Case Cover Sheet. An example of an equally acceptable, but somewhat complicated, document title is Plaintiff's Response to Defendant's Response to Plaintiff's Response to Defendant's Motion for Summary Judgment. [37] Document:Type is a value usually found in a case management system code table and used by the court to identify types of documents. A court's Policy XML should include a table with Document:Type values. If a document type list exists in Policy XML, then the Document:Type element must be populated with a value from this list. Document:Type is not the Document:Title, although the values may be similar or the same. Usually, the Document:Type is more general than Document:Title. [38] Document:Type is not the type of electronic file (e.g., it should be distinguished from a document's MIME type). See Document:Title and Document:Code. [39] For a document tile such as Plaintiff's Response to Defendant's Response to Plaintiff's Response to Defendant's Motion for Summary Judgment, an example document type might be Motion for Summary Judgment or Response to Motion for Summary Judgment. Application Use[40] Document:GenericType is a general document type value that is used by applications to match and categorize more specific Document:Type values used in a case management system. Document:GenericType values are intended primarily for application use, not necessarily for human use, but could be used for both. Examples[41] For a document tile such as Plaintiff's Response to Defendant's Response to Plaintiff's Response to Defendant's Motion for Summary Judgment, with a document type such as Motion for Summary Judgment or Response to Motion for Summary Judgment, the document generic type might be Motion or Response. [42] Other example Document:GenericType values include Affidavit (a) Answer (b) Brief (c) Certificate of Service (d) Complaint (e) Withdrawal Of Counsel (f) Correspondence (g) Counterclaim (h) Crossclaim (i) Demand for Jury Trial (j) Demand for Speedy Trial (k) Discovery (l) Dismissal (m) Exhibit (n) Interpleader (o) Judgment (p) Jury List (q) Motion (r) Notice (s) Order (t) Sentence (u) Service (v) Subpoena (w) Transcript (x) Verdict (y) Verification (z) Warrant. The values should be specified in a court's Policy XML. These values may be varied by vendors or courts, by agreement of parties involved in exchanging information. Triggering Special Processing: Fee Waiver Example[43] Certain types of documents require special processing by a court. The Document:GenericType element provides the ability to trigger special processing based on the type of document filed. The following fee waiver example shows how this is done. [44] In California, it is possible to request a waiver of filing fees from a court (Government Code section 68511.3 and California Rule of Court 985 control fee waivers). To request a fee waiver, a filer must file a motion for a fee waiver. If everything in the filing is correct, then the court must accept the filing just as if the filer had included a filing fee. The clerk has the ability in some situations to grant the motion for fee waiver. Other procedures are required to deny the motion. If the motion is not denied within five days, then it is granted automatically by operation of law. The legal requirements for fee waivers results in the need for special processing rules for incoming filings that include a motion for a fee waiver. [45] The following processing rules must be used to trigger special processing based on a Document:GenericType: Processing Rule | Description |
---|
Create Generic Type Value in Policy XML | Create a generic type value in Policy XML within a Policy:Table/Table:Name that has the value Document Types. In this example, the generic type value might be Fee Waiver. | Filing Application Must Use Generic Type Value | Filing applications must use the generic type when filing a document, such as Motion for Fee Waiver, intended to trigger special processing. In this example, the Document:GenericType element must be populated with the value Fee Waiver. | Receiving Application Must Check For Generic Type Value | For each incoming filing, the receiving application must check for any generic type that is meant to trigger special processing. | Trigger Special Processing | When a receiving application recognizes a special generic type, such as Fee Waiver, then its discovery should trigger special processing. In this case, the receiving application would bypass the fee collection process and would put the filing in a special queue that would prompt the court clerk to determine whether to grant or deny the fee waiver request prior to the expiration of the statutory five day deadline. |
[46] Policy XML and filing applications must use the Document:GenericType element rather than the Document:Type element to trigger special processing. This allows a common string to be used for multiple types of more specific documents. [47] Document:Code is a code value usually found in a case management system code table used by the court to identify types of documents. A case management system document code is usually associated with human-readable document type value, represented in this schema as Document:Type. Courts should make this association in Policy XML. See Document:Type. Child Element(s) | minOccurs | maxOccurs | FiledBy | 1 | unbounded |
[48] The Document:FiledBys element is a container element for one or more Document:FiledBy elements. [49] The Document:FiledBy element is an IDREF that must refer to a Role:Qualifier ID value. A filed by party is a person or organization that has an association to a document and that is a litigant named on the document and responsible for filing the document. For example, a Plaintiff would be a filed by party if the Plaintiff files the document naming the Defendant. Likewise, the Defendant would be the filed by party if the Defendant files a document naming the Plaintiff. Child Element(s) | minOccurs | maxOccurs | RefersTo | 1 | unbounded |
[50] The Document:RefersTos element is a container element for one or more Document:RefersTo elements. [51] The Document:RefersTo element is an IDREF that must refer to a Role:Qualifier ID value. A refers to party is a person or organization that has an association to a document and that is a litigant named on the document and not responsible for filing the document. For example, a Plaintiff would be a refers to party if the Defendant files the document naming the Plaintiff. Likewise, the Defendant would be the refers to party if the Plaintiff files a document naming the Defendant.
Document File Attributes[52] Document:File has nine attributes, three of which are required attributes. The required attributes are (a) Encoding, (b) MIMEType, and (c) FileSize. The optional attributes are (a) Namespace, (b) Username, (c) Password, (d) Encrypted, (d) Algorithm, and (e) Expiration. The following sections explain these attributes and how they function together. Document Encoding, MIMEType, and Namespace[53] The attributes Encoding, MIMEType, and Namespace provide information about the electronic document format and encoding. The attribute Encoding is a required attribute that describes the encoding of the document. The Encoding attribute's data type is a simpleType Encodings. Encodings has three values (a) Base64, (b) Link and (c) Absent. The value Base64 means that the electronic document is base64-encoded and then the encoded text is placed in Document:File or Document:Page element. The value Link means that the electronic document is available outside of the Filing XML or Confirmation XML via a link (to a URL or a local drive) included in the Document:File or Document:Page elements. The value Absent means that neither a base64-encoded document nor a link is included in this Document:File element. [54] The value Absent may only be used in Confirmation XML to report the disposition of a filed document. The value Absent may not be included in Filing XML. The value Absent may be useful, for example, when the Document:FilingStatus value is Pending, in which case there is no need to send the document back to the filing application. Even if the document is absent, the Document:Key value must be populated so filing applications can match filed documents with document dispositions. This is a rare exception where it is acceptable to include an empty element in an XML document. [55] The required MIMEType attribute can be one of several standard MIME types values enumerated in the simpleType MIMETypes. A court may limit the MIME types (i.e., the document formats) permitted to be filed into the court by setting restrictions in Policy XML. [56] The Namespace attribute is an optional attribute that should be used if the document passed has a namespace associated with it. XML documents often have namespaces associated with them. The Namespace value should be the namespace of the XML document's root element. A court may limit the types of documents with namespaces permitted to be filed in the court by using Policy XML. File Size[57] The attribute FileSize is required to express the size of the electronic document included in, or linked from, the Document:File element. The FileSize attribute value must be expressed as bytes. The number of bytes must be the size of the file prior to base64-encoding. The FileSize value may be useful to applications that attempt to download a document from a link, either to calculate the time-to-download or to verify the file size upon download completion. Likewise, the FileSize value may be useful to applications that wish to verify whether a base64-encoded document has been decoded properly. While there is no technical guarantee that the FileSize value will be accurate, this value may prove useful if it is accurate. Username, Password, and Related Attributes[58] The Username and Password attributes are used when downloading a document from a link that is password protected. These attributes are populated by a filing application so that a receiving application does not have to manage username and password information for multiple filing applications. Since it is the filing application that has posted the document(s) to a web server for downloading using a link (that points back to the filing application's server), it is the filing application that is in the best position to manage and send the username and password information. [59] It is possible for the filing application either to use the same username and password for all documents or to use a different username and password for individual documents, provided that any username and password provides access to the document(s). The receiving application is responsible only for parsing the username and password data from the Username and Password attributes and for using those values to authenticate its request for the document(s). [60] The Encrypted attribute is an optional attribute with a default value equal to false. If the Encrypted attribute value is false, then this means that the Username and Password attribute values are unencrypted. If the Encrypted attribute value is true, then this means that the Username and Password attribute values are encrypted. [61] If the Username and Password values are encrypted, then the encryption algorithm name must be specified in the Algorithm attribute. The Algorithm attribute value may be any value agreed by the filing application(s) and the receiving application. The value can be the actual name of the algorithm or a hint for the receiving application to use to determine the algorithm. In any case, the Algorithm attribute must provide enough information to the receiving application so that the receiving application can decrypt the username and password. Expiration[62] The Expiration attribute is an optional attribute that provides an expiration date and time for the link or the username and password. Once the link or the username and password expire, there is no guarantee that the document at the link provided will continue to be available. Applications relying on links must download documents and links prior to the expiration date and time. Filing applications must ensure that documents are available until the expiration date and time. If an expiration date and time is not provided, then filing applications must ensure the document is available for three business days after the time of filing. [63] The Document:DataFile element is used to add document type specific Plug-In XML. If a case management or document management system requires additional data, not defined in this Document schema, then applications must use the Document:DataFile element to specify additional document data. For example, if a Case Cover Sheet document required additional, document specific data, then a Plug-In schema should be defined for coversheet data and coversheet data conforming to the schema should be sent in the Document:DataFile element. [64] Document:FilingStatus is the status of the document when the Confirmation:FilingStatus value is equal to Partial. 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. [65] Document:FilingStatus can have the following values: (a) Received, (b) Accepted, (c) Pending, (d) Rejected, and (f) Error. [66] The value Received means that, at least, the receiving application acknowledges receipt of the document. Received has no other meaning. [67] The value Accepted means that the document 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.) [68] The value Pending means that the document is still pending as of the Confirmation:Date and Confirmation:Time. [69] The value Rejected means that the document has been rejected by the court at a time subsequent to the initial receipt. It is, therefore, possible that a filer could receive a Received status, but that the document might later be rejected. [70] The value Error means that there has been a technical error and the document is unreadable after decoding or unavailable for download. [71] The value Absent used in the Document:File element's Encoding attribute may be useful when the Document:FilingStatus element is used in situations where the filed document has not changed. In this situation, an application may wish to send the disposition of a document in Confirmation XML without sending the document, since the document has not changed. See the Document:File element Encoding attribute. [72] Document:Hash is a hash value of the document. The Document:Hash has an attribute Algorithm that may be one of four values (a) SHA-1 (b) SHA-256 (c) SHA-384 (d) SHA-512. [73] This element has been added as a result of a requirement in Standards for Electronic Filing Processes (February 26th, 2003) to use FIPS 180-2 for message integrity. FIPS 180-2 states "This standard specifies four secure hash algorithms, SHA-1 1 , SHA-256, SHA-384, and SHA-512. All four of the algorithms are iterative, one-way hash functions that can process a message to produce a condensed representation called a message digest. These algorithms enable the determination of a message's integrity: any change to the message will, with a very high probability, result in a different message digest. This property is useful in the generation and verification of digital signatures and message authentication codes, and in the generation of random numbers (bits)." [74] Contrary to assertions made in Standards for Electronic Filing Processes (February 26th, 2003) courts and service providers using hashes without digital signatures should understand that storage of many hashes and/or sending a hash back to a filer in a confirmation message is not a foolproof method of assuring message integrity. Without digital signatures, it is possible for parties on either side of a transaction to alter a document, produce a new hash value, and claim that the new document is the authentic document using the new hash as proof. In such a case, there could be a dispute as to which party is actually in possession of the authentic document. Because either a filer or a filer's staff or a court or a court's staff could be the malefactor, there can be no presumption, using a hash function alone, that one side or the other is telling the truth. Additional security procedures are required. [75] Applications wishing to use two-key cryptosystems or public key infrastructure should use the W3C XML Signature specification. [76] Document:Confidential is an optional element of type boolean. When set to true, Document:Confidential means that the filer believes there is a statutory reason that the document should remain confidential and not be published for public consumption. The receiving application should behave according to policy set by the court. [77] If the Filing:Confidential element value is equal to true, then all documents in a filing are requested to be confidential. As a result, if the Filing:Confidential element value is equal to true, then the Document:Confidential element must be absent or it must be ignored, if present. [78] Document:Sealed is an optional element of type boolean. When set to true, Document:Sealed means that the filer believes there is a statutory reason that the document should be sealed by the court and not be published either for for public consumption or to the court clerk. Document:Sealed is distinguished from Document:Confidential, in that Document:Confidential is merely a filer's request to keep the filing confidential from the public, whereas Document: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. Child Element(s) | minOccurs | maxOccurs | Extension | 1 | unbounded |
[80] Document:Extensions is a container element for one or more Document:Extension elements. A Document:Extension element includes a generic name/value pair that allows applications to send information not included in the document schema. See Extension Schema. [81] Document:FilingStatusMessage is a message that qualifies or explains the reason for the value in Document:FilingStatus. For example, Document:FilingStatusMessage might include the reason the court rejected a document. [82] A Document:Extension is a generic name/value pair that allows applications to send information not included in the document schema. See Extension Schema. |