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

Schema Namespace and Documentation
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/
Schema Prefix
Policy
Schema Repository Location
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/Policy.xsd
 
Table of Contents
1. Elements
 Internal
  1.1. Policy
  1.2. Name
  1.3. Version
  1.4. MajorVersion
  1.5. MinorVersion
  1.6. PublicationDate
  1.7. PublicationHour
  1.8. EffectiveDate
  1.9. EffectiveHour
  1.10. Contacts
  1.11. CourtDivisions
  1.12. CodeTables
  1.13. Fees
  1.14. AcceptedCreditCards
  1.15. CreditCardType
  1.16. MaximumFilingSize
  1.17. MaximumDocumentSize
  1.18. DelimitExhibits
  1.19. AcceptedMIMETypes
  1.20. MIMEType
  1.21. AcceptedEncodings
  1.22. Encoding
  1.23. AcceptedReplyToProtocols
  1.24. ReplyToProtocol
  1.25. UTCOffset
  1.26. UTCOffsetDaylightSavings
  1.27. Exchanges
  1.28. AssociatedPolicies
  1.29. HumanPolicies
  1.30. Extensions
 External
  1.31. AssociatedPolicy
  1.32. Key
  1.33. ClerkOfCourt
  1.34. CourtDetails
  1.35. CourtDivision
  1.36. Contact
  1.37. CodeTable
  1.38. Fee
  1.39. Payment
  1.40. HoursOfOperation
  1.41. TestCreditCard
  1.42. Exchange
  1.43. HumanPolicy
  1.44. Extension
2. Simple Types
  2.1. MIMETypes
  2.2. Encodings
  2.3. ReplyToProtocols
  2.4. DeliveryFormats
  2.5. DocumentVersions
  2.6. Hours
  2.7. VersionNumber
3. Imported Schemas
  3.1. Attributes
  3.2. Address
  3.3. CourtDetails
  3.4. CreditCard
  3.5. Extension
  3.6. Fee
  3.7. Key
  3.8. Organization
  3.9. Person
  3.10. AssociatedPolicy
  3.11. CodeTable
  3.12. Contact
  3.13. CourtDivision
  3.14. Exchange
  3.15. HoursOfOperation
  3.16. HumanPolicy
  3.17. Payment
4. Change History
  4.1. 2003-02-18
  4.2. 2003-02-23
  4.3. 2003-04-29
  4.4. 2003-06-20
  4.5. 2003-07-01
  4.6. 2003-07-02
  4.7. 2003-07-23
  4.8. 2003-07-26
  4.9. 2003-07-27
  4.10. 2004-02-29
  4.11. 2004-04-20
  4.12. 2004-04-26
  4.13. 2004-04-27
  4.14. 2004-04-27
  4.15. 2004-04-30
  4.16. 2004-05-10
  4.17. 2004-08-02
  4.18. 2004-08-05
  4.19. 2004-09-03
  4.20. 2004-09-14
  4.21. 2005-06-05
  4.22. 2005-06-25
  4.23. 2005-08-20
  4.24. 2005-09-13
  4.25. 2005-09-23
  4.26. 2005-10-05
  4.27. 2008-10-01
  4.28. 2008-11-13
5. Legal Notices
6. Authors and Contributors

1. Elements

1.1. Policy:Policy
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Key11
Name11
Version11
PublicationDate11
PublicationHour11
EffectiveDate11
EffectiveHour11
ClerkOfCourt01
CourtDetails11
HoursOfOperation01
Contacts01
CourtDivisions01
CodeTables01
Fees01
Payment01
AcceptedCreditCards01
TestCreditCard01
MaximumFilingSize01
MaximumDocumentSize01
DelimitExhibits01
AcceptedMIMETypes01
AcceptedEncodings01
AcceptedReplyToProtocols01
UTCOffset01
UTCOffsetDaylightSavings01
Exchanges01
AssociatedPolicies01
HumanPolicies01
Extensions01

Introduction

[1]  This document is the California Second Generation Electronic Filing Specifications (2GEFS) Court Policy 2.0 Specification (Policy XML or Court Policy). The web-based documentation is broken into several web pages, one for each schema. The Adobe PDF documentation is one PDF document for all schema unique to Policy XML and an additional PDF document that includes documentation for Building Block schemas. Building Block schemas are common to Filing XML, Confirmation XML, Notice XML, and Policy XML. Both the web-based documentation and the PDF documentation contain hypertext links to all other schema documentation and the schema themselves. An accompanying document, 2GEFS Concepts, augments this specification with a high-level overview of terminology, models, relationship among specifications, and related concepts.

[2]  Please go to the following links to find these and other resources:

[3]  California AOC EFiling Standards Website: http://www.courtinfo.ca.gov/programs/efiling/standards.htm#2gefs.

[4]  California AOC Terms of Use: http://www.courtinfo.ca.gov/programs/efiling/termsofuse.htm.

[5]  Policy Specification: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/.

Relevant Schemas and Schema Versions

[6]  The following schemas and schema versions are relevant to Policy XML and an ancillary specification, Policy Index:

Schema NameVersion and Namespace
Court Policy 01http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/01/
Court Policy Test05http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/
Court Policy 02http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/
Policy Index Test 01http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/Index/Test01/
Policy Index Test 02http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/Index/Test02/
Policy Index 01http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/Index/01/

[7]  Court Policy 01 is the first official 2GEFS Court Policy Specification published August 5, 2004. Court Policy 01 will be superseded by Court Policy 02 in the future. Court Policy Test05 is a pre-release version of Court Policy 02 that is subject to change based on comment and testing.

[8]  Policy Index Test01 is the first pre-release version of a future Policy Index 01. Policy Index Test02 is the second pre-release version of Policy Index 01.

[9]  Court Policy 01 includes publication rules that are different than the publication rules in all versions of Policy Index and newer versions of Court Policy (i.e., Court Policy Test05 and Court Policy 02). The next recommended versions of Court Policy and Policy Index will have the same publication rules, as will all pre-release versions. In sum, Court Policy 01 publication rules are obsolete.

[10]  Differences between Court Policy 01 publication rules and Court Policy 02 and Policy Index publication rules are noted in this specification.

Overview

[11]  Policy XML includes information specific to a court and a court's divisions, departments, and groups, if such subdivisions exist. The purpose of Policy XML is to encode unique information about a court in a standard, machine-readable way. The benefit of Policy XML is that court filing applications can consume information from many courts in the same way without the need to write custom code for each court. Policy XML is, in other words, a court configuration file.

[12]  Policy XML could contain a wide variety of information. Attempting to specify too much information in Policy XML is problematic because of the resulting complexity and difficulty of writing code for all possible uses. Accordingly, Court Policy 01 included only a minimum of what could be in Policy XML. The goal of Court Policy 01 was to keep the Policy XML as simple as possible to facilitate use and adoption. Court Policy 02 expands on the original version by including additional policy information. This has been done, in part, because applications written for Court Policy 01 are mature and, in part, because implementation experience has uncovered additional requirements.

[13]  Policy XML includes the following information about a court: (a) unique identifiers for the court and its subdivisions, (b) court name and contact details, (c) clerk of court name and contact details, (d) hours of operation (e) code tables (f) fee schedules, (g) court payment details (enough information to pay a court using credit cards or Automated Clearing House (ACH) payment network), (h) a number of technical values such as accepted credit cards, test credit card information, accepted MIME types, maximum file size for documents and filings, supported transmission protocols for confirmations, and pointers to exchange policies, and (i) human readable policy statements.

Publication Guidelines

[14]  As a general rule, a court should publish a Court Policy publicly, preferably over the Internet, in a Policy Repository that follows the rules of this specification and the Policy Index specification. Implementing a standard means of publication is not necessary, however, for the use of Court Policy. A Court Policy file itself is useful on its own. In particular, applications that do not have access to the Internet or that only have access to low bandwidth network connections may benefit from a Court Policy file that does not follow the publication rules described in this specification.

[15]  A Court Policy can be used from a remote repository or from a local repository. A remote repository might reside on a court's server. A local repository might reside on a service provider's server or within a desktop application. There is no requirement to use a Court Policy from a remote repository on a court server. In fact, local use is encouraged and remote use is discouraged. Applications are encouraged to download policies from remote repositories, store policies in local repositories, and then use local policies, provided the policies have not expired.

[16]  If privacy or security is a concern, it is suggested that courts review the information in their policy and eliminate any information deemed sensitive. Most information in a Court Policy is public information, with the possible exceptions of (a) the court's bank routing number and account number and (b) phone numbers and email addresses that provide direct access to court staff. There is no requirement to publish such information, so if a court prefers to keep the information private or distribute it through other channels (for example, in a service provider agreement) then such a decision is acceptable and preferable to password protecting or otherwise limiting access to the policy.

[17]  Courts should consider posting acceptable use policies applicable to Court Policy users. An acceptable use policy might limit the number of times per day or the ways in which a user's application can access the court's servers to obtain Court Policy files.

Pre-Publication

[18]  Courts are encouraged to pre-publish Policy XML several weeks in advance and no later than three days in advance. Pre-publication provides time for applications to implement and test a new policy. While this specification permits publication with as little as one hour notice, only in extreme or emergency situations should courts publish a new policy on such short notice.

Publication Rules

[19]  The following publication rules, also described in the Policy Index specification, are rules for publishing Court Policy. The publication rules include rules for the location of the Court Policy and the naming convention for the Court Policy directories and file names.

[20]  A Court Policy and Court Policy Index must be published at an HTTP-accessible path with the following parts, in the following order:

[21]  Part 1: Domain: Domain means any valid domain name. For example: http://www.courtinfo.ca.gov/.

[22]  Part 2: CourtPolicies Directory: The directory CourtPolicies.

[23]  It may not always be possible to create a CourtPolicies directory at a given www domain alias, such as www.courtinfo.ca.gov. If it is not possible to create a CourtPolicies directory at an organization's www domain, then the domain owner must create a different domain alias, such as policies.courtinfo.ca.gov. For example, the CourtPolicies directory could be at either:

[24]  http://www.courtinfo.ca.gov/CourtPolicies/

[25]  or

[26]  http://policies.courtinfo.ca.gov/CourtPolicies/

[27]  The recommended domain alias prefix is "policies" as shown in the example above. Any domain alias prefix is acceptable.

[28]  A Policy Repository must contain an index.xml file in the CourtPolicies directory. This index.xml file is called a Primary Policy Index (see the Policy Index specification for a detailed definition of terms). This is a change from the Court Policy 01 specification. For example, the following file must exist, depending on the domain name:

[29]  http://www.courtinfo.ca.gov/CourtPolicies/index.xml

[30]  or

[31]  http://policies.courtinfo.ca.gov/CourtPolicies/index.xml

[32]  The Primary Policy Index file must contain either (a) a direct path to every Court Policy in the Policy Repository or (b) a direct path to a Local Policy Index that, in turn, includes a direct path to every Court Policy in the associated Local Policy Repository. The end result and most important requirement is that the Primary Policy Index must include a direct or indirect reference to every Court Policy in the Policy Repository. Optionally, additional indirect references may be made to policy indexes in Remote Policy Repositories.

[33]  Part 3: Country Directory: A directory using a two-letter ISO 3166 Country Code.

[34]  Part 4: State Directory: The fully spelled U.S. Postal Service State Name with no spaces and in UpperCamelCase.

[35]  Part 5: Optional Subdirectories: Optionally, additional subdirectories may be added to represent smaller jurisdictional or geographic regions, such as County or Municipality. Every directory that contains a Court Policy must also contain an index.xml file. For example:

[36]  http://www.courtinfo.ca.gov/CourtPolicies/US/California/Sacramento/index.xml

[37]  http://www.courtinfo.ca.gov/CourtPolicies/US/California/ContraCosta/index.xml

[38]  http://www.courtinfo.ca.gov/CourtPolicies/US/California/SanMateo/index.xml

[39]  Note: Part 5 has been added to this specification and is different than Court Policy 01 publishing rules.

[40]  Part 6: FileName: The filename for the Court Policy, in the following format:

[41]  OrganizationKey_YYYY_MM_DD_VerX_Y_Y.xml

[42]  In the above format, OrganizationKey is a unique identifier issued to the court by a state policy authority; YYYY_MM_DD is the year, month, and day of publication; VerX_Y_Y is the major and minor version numbers of the Court Policy; and .xml is the file extension.

[43]  Note, Part 6 is formerly Part 5 in the Court Policy 01 specification. This rule is different than the Court Policy 01 rule in that hours, minutes, and seconds in the filename has been replaced by the Court Policy version number.

[44]  The OrganizationKey in the filename must match the OrganizationKey in the Court Policy itself. Further, the date in the filename must match the Policy:PublicationDate in the Court Policy itself. The major and minor version numbers must match the Policy:Version and its children elements in the Court Policy.

[45]  For example, the following are acceptable Court Policy paths:

[46]  http://www.courtinfo.ca.gov/CourtPolicies/US/California/USCASacramentoSuperior_2005_05_02_Ver1_2_0.xml

[47]  http://policies.courtinfo.ca.gov/CourtPolicies/US/California/USCASacramentoSuperior_2005_05_02_Ver1_2_0.xml

[48]  http://www.courtinfo.ca.gov/CourtPolicies/US/California/Sacramento/USCASacramentoSuperior_2005_05_02_Ver1_2_0.xml

[49]  http://policies.courtinfo.ca.gov/CourtPolicies/US/California/Sacramento/USCASacramentoSuperior_2005_05_02_Ver1_2_0.xml

[50]  Each directory in which a Court Policy resides must have a file within it named index.xml. The index.xml must contain metadata about the files in the directory as defined by the Policy Index specification.

Policy Effective Date

[51]  It is possible to pre-publish a Court Policy using a future Policy:EffectiveDate value. In this case, the newest policy in the directory will not be the current policy. Applications must check the most recent policy for its effective date. If the date has not yet occurred, the application must check the next to last policy and so on, until it finds an effective policy.

Archiving Past Policies

[52]  Past Court Policies must be archived and indexed in the directory for a reasonable time. This is an important rule because past electronic filing transactions would have relied on past policies. In case of a dispute over a past transaction, the past policy is necessary to understand all facts and circumstances surrounding the transaction.

[53]  For example, assume a past policy includes a filing fee for a complaint that is $100. A new policy includes a filing fee for a complaint that is $110. If a filing is rejected because the fee tendered is $100, rather than $110, and if the filer disputes the reason for rejection, then the issues of the dispute are (a) whether the filer submitted the filing at a time when the past or present policy was in effect and (b) whether, in fact, the past filing fee was $100. Both the past policy and the present policy are necessary to answer these questions.

[54]  This specification does not define a reasonable time. Organizations are encouraged to archive policies for longer, rather than shorter, periods while implementation experience is accumulated that sheds light on the length of a reasonable time. As a baseline, this specification suggests that two years is a reasonable time to archive a policy.

Dynamic Publication Not Allowed

[55]  Related to the archiving rule, dynamic publication of Court Policies is prohibited. Dynamic publication is publication of a court policy at one URL directly from a data source, such as a database, that can change. Dynamic publication results in a variable stream of data that may change each time the URL is accessed. It is acceptable (and, indeed, encouraged) to dynamically generate static court policy files with unique version numbers. Once the policy file has been generated, however, the file must remain static in a policy repository; it must not be changed in any way; and it must be indexed. Dynamic publication (by definition) allows the policy to change each time a change is made to a data source without changing the policy file name and version number. This, in turn, opens the door for disputes about what information was published in a policy at any given time. For example, there would be no good or consistent record available to sort out the $100 or $110 fee dispute described in the example above.

Publication, Effective, and Expiration Dates and Times

[56]  This section and the following three sections provide definitions, rules, and examples for Court Policy publication, effective, and expiration dates and times. The definitions, rules, and examples apply to both Court Policy and to Policy Index specifications.

[57]  The purpose of these rules is to allow a court to publish a policy for an indefinite period without specifying an expiration date. Under the rules, a court never needs to unnecessarily expire a good policy. At the same time, the rules allow a court to expire an existing policy on as short as sixteen minutes notice simply by publishing a new policy. Under these rules, the longest that a bad policy can be in effect (once the policy is discovered as bad) is one hour. The rules require applications to check for new policies every hour or 24 times a day. The rules also allow for the advanced publication of policies for testing purposes.

Publication, Effective, and Expiration Dates and Times - Definitions

[58]  This section provides basic definitions for a number of terms relevant to Court Policy publication and use. The definitions for publication date, publication hour, effective date, and effective hour correspond to XML elements in both Court Policy and Policy Index specifications. The definitions for expiration date and expiration hour are determined based on the effective date and the effective hour of the newest policy in a Policy Repository. As a result, there is no corresponding XML elements for expiration date and expiration hour in either specification.

[59]  Publication Date: A policy's publication date is the date on which a court makes the policy available in a Policy Repository. A policy is not necessarily effective on its publication date.

[60]  The publication date is expressed in Policy XML as Policy:PublicationDate and in Policy Index XML as Index:PublicationDate.

[61]  Publication Hour: A policy's publication hour is the top of the hour in which a court makes the policy available in a Policy Repository, provided that the policy is made available in the first forty-five minutes of the hour. The hour is expressed in two-digit military time.

[62]  For example, if a policy is published at 10:32 a.m., then the publication hour would be 10. If the policy is published at 8:43 p.m., then the publication hour would be 20. If the policy is published at 12:10 p.m., then the publication hour would be 12. If the policy is published at 12:10 a.m., then the publication hour would be 00. If the policy is published at 11:12 p.m., then the publication hour would be 23.

[63]  If a policy is published in the last fifteen minutes of an hour, then the publication hour must be the top of the next hour. For example, if a policy is published at 8:50 p.m., then the publication hour must be 21, not 20.

[64]  A policy's publication hour must be at least one hour prior to the policy's effective hour. As a result, a policy is never effective in its publication hour.

[65]  Publication hour is expressed in Policy XML as Policy:PublicationHour and in Policy Index XML as Index:PublicationHour.

[66]  Effective Date: A policy's effective date is a date after which the policy is published and on which a policy is in force and applicable to the court. When a policy is effective, the values in it must be used in electronic filings sent to the court.

[67]  Effective date is expressed in Policy XML as Policy:EffectiveDate and in Policy Index XML as Index:EffectiveDate.

[68]  Effective Hour: A policy's effective hour is top of the hour in which a policy is in force and applicable to the court. Effective hour is expressed in two-digit military time. When a policy is effective, the values in it must be used in electronic filings sent to the court.

[69]  Policies can only become effective at the top of an hour. For example, a policy can only become effective at 10:00 a.m. or 1:00 p.m., but not 10:15 a.m. or 1:23 p.m.

[70]  Effective hour is expressed in Policy XML as Policy:EffectiveHour and in Policy Index XML as Index:EffectiveHour.

[71]  Effective Policy: An effective policy is one that has reached its effective date and effective hour and is not yet expired.

[72]  Expiration Date: A policy's expiration date is the date on which the policy is no longer in force. When a policy is expired, the values in it must not be used in electronic filings sent to the court.

[73]  Expiration date is not expressed in Policy XML or Policy Index XML. Instead, the expiration date is calculated based on the rules in this specification by determining the effective date of the most recently published Policy XML file.

[74]  Expiration Hour: A policy's expiration hour is the bottom of the hour immediately preceding the effective hour of the most recently published Policy XML file. When a policy is expired, the values in it must not be used in electronic filings sent to the court.

[75]  Expiration hour is not expressed in Policy XML or Policy Index XML. Instead, the expiration hour is calculated based on the rules in this specification and by determining the effective hour of the most recently published Policy XML file.

Publication, Effective, and Expiration Dates and Times - Rules

[76]  The following are ten rules that govern Court Policy publication and use. Generally, the purpose of these rules is to allow a court to publish a policy for an indefinite period without specifying an expiration date, yet also to allow a court to expire an existing policy on as short as sixteen minutes notice. As a result, the rules require applications to check for new policies every hour or 24 times a day. The rules also allow for the advanced publication of policies for testing purposes.

[77]  Rule 1 - Most Recent Effective Policy Rule: The most recent Policy XML published in a court's Policy Repository is the court's effective policy, unless the policy has not yet reached its effective date and effective hour. A court can only have one effective policy at a time.

[78]  Rule 2 - One Hour Rule: If a policy is effective at the top of an hour, then it remains in effect for the entire hour.

[79]  Rule 3 - Automatic Expiration Rule: A policy automatically expires at the bottom of the hour, unless there is no new policy that has reached its effective date and effective hour. If there is no new effective policy, then the most recent effective policy remains in effect. If there is a new effective policy at the top of the hour, then the policy that was in effect in the previous hour automatically expires.

[80]  Rule 4 - Top of the Hour Publication Rule: Publication time must always be at the top of the hour in which the policy is published in a Policy Repository. For example, if a policy is published at 10:14 a.m., then the publication time must be 10:00 a.m.

[81]  Rule 5 - Top of the Hour Effective Rule: A new policy is never effective in the hour that it is published. A new policy may not be effective sooner than the top of the hour after the hour in which it is published. For example, if a policy is published at 10:14 a.m., then the policy's publication hour is 10:00 a.m. and the effective hour may not be sooner than 11:00 a.m. The effective date and the effective hour may be as far into the future as the court wishes.

[82]  Rule 6 - Publication Timing Rule: New policies should be published in the first half hour of any hour (i.e., between hh:00 and hh:29). New policies may be, but should not be, published between half past the present hour and quarter until the next hour (i.e., between hh:30 and hh:44). New policies must not be published in the last quarter of an hour (i.e., between hh:45 and hh:59). New policies published in the last quarter of an hour may be ignored and must have an effective hour no sooner than the top of the hour after the next hour. For example, a policy published at 9:55 a.m. must have an effective hour no sooner than 11:00 a.m. on the same day.

[83]  Rule 7 - Reliance Timing Rule: Application that rely on Policy XML must check for a new policy every hour and must check during the last quarter of the hour (e.g., between hh:45 and hh:59).

[84]  Rule 8 - No Changing Rule: Published policies must never be changed in any way.

[85]  Rule 9 - New Version and Filename Rule: New policies must be published with a new version number and a new filename.

[86]  Rule 10 - Indexing Rule: New policies must be indexed using Policy Index XML. Applications are only required to check Policy Index XML for new policies.

Publication, Effective, and Expiration Dates and Times - Examples

[87]  This section includes examples and analysis of how publication, effective, and expiration dates and times function together.

[88]  The following table illustrates several policy versions for a single court that will be used in this section's examples. The table includes the following abbreviations: Ver (version), PD (publication date), PH (publication hour), UT (upload time), EfD (effective date), EfH (effective hour), ExD (expiration date), and ExH (expiration hour).

-VerPDPHUTEfDEfHExDExH
Original Policy1.0.01/1/200510:0010:141/1/200511:002/4/200511:00
New Policy After One Month (72 Hour Pre-publication)1.0.12/1/200511:0011:342/4/200511:003/2/200509:00
New Policy After One Month (24 Hour Pre-Publication)1.0.23/1/200509:0009:053/2/200509:00Never EffectiveNever Effective
New Policy One Hour After Publication Date1.0.33/1/200504:0004:103/2/200509:003/2/200510:00
New Policy One Hour After Effective Date1.0.43/2/200509:0009:073/2/200510:00--

[89]  Policy 1.0.0 is the courts original policy. The court uploads and indexes the policy on January 1st, 2005 at 10:14 a.m. According to Rule 4 - Top of the Hour Publication Rule, the resulting publication hour is 10:00 a.m. According to Rule 5 - Top of the Hour Effective Rule, the policy may not be effective sooner than 11:00 a.m. on the same day. In this case, the policy has an effective date that is January 1st, 2005 and an effective hour at 11:00 a.m.

[90]  Policy 1.0.1 is the court's second published policy. The court uploads and indexes the policy on February 1st, 2005 at 11:34 a.m. According to Rule 4 - Top of the Hour Publication Rule, the resulting publication hour is 11:00 a.m. According to Rule 5 - Top of the Hour Effective Rule, the policy may not be effective sooner than noon on the same day. However, the court has published Policy 1.0.1 72 hours in advance of its effective date and effective hour. As a result, the effective date is February 4th, 2005 and the effective hour is 11:00 a.m. The effective hour may be any value, since the policy has been published no sooner than one hour prior to its effective date.

[91]  According to Rule 3 - Automatic Expiration Rule, Policy 1.0.0 expires when Policy 1.0.1 becomes effective. According to Rule 7 - Reliance Timing Rule, applications that rely on Policy XML have 72 hour advanced notice of the new policy, since the court published the policy 72 hours prior to its effective date and effective hour.

[92]  Policy 1.0.2 is the court's third published policy. The court uploads and indexes the policy on March 1st, 2005 at 9:05 a.m. According to Rule 4 - Top of the Hour Publication Rule, the resulting publication hour is 9:00 a.m. In this case, the court has published the policy one day in advance. The effective date is March 2nd, 2005 at 9:00 a.m.

[93]  However, shortly after publication of Policy 1.0.2, an application that relies on court policy discovers a mistake in the policy and reports an error. This error is communicated to the court. According to Rule 1 - Most Recent Effective Policy Rule, Policy 1.0.1 is still in effect since Policy 1.0.2 has not yet reached its effective date and effective hour.

[94]  Realizing the mistake, the court publishes a corrected Policy 1.0.3, the court's fourth published policy. The court uploads and indexes the policy on March 1st, 2005 at 4:10 p.m. so, according to Rule 4, the publication time is 4:00 p.m. Policy 1.0.2 and the corrected Policy 1.0.3 have the same effective date and effective hour: March 2nd, 2005 at 9:00 a.m. The result is that Policy 1.0.2 (the policy with the mistake in it) is never effective (and, as a result, can never expire). Instead, according to Rule 1 - Most Recent Effective Policy Rule, Policy 1.0.3 becomes effective on March 2nd, 2005 at 9:00 a.m.

[95]  In accordance with Rule 8 - No Changing Rule and Rule 9 - New Version and Filename Rule, the court does not change or republish Policy 1.0.2. Instead, the court publishes a new Policy 1.0.3. These rules are in place to ensure that there is no confusion between the bad Policy 1.0.2 and the good Policy 1.0.3. Rule 7 - Reliance Timing Rule ensures that applications will find the new Policy 1.0.3 prior to the effective date for both Policy 1.0.2 and Policy 1.0.3, which are both set to be March 2nd, 2005 at 9:00 a.m.

[96]  On March 2nd, 2005 at 9:00 a.m., Policy 1.0.3 becomes effective. At the same time, according to Rule 3 - Automatic Expiration Date, Policy 1.0.1 expires. Policy 1.0.2, whose effective date is the same as Policy 1.0.3, does not have an expiration date because, according to Rule 1 - Most Recent Effective Policy Rule, Policy 1.0.2 was never effective.

[97]  At 9:01 a.m. the court determines that a fee in Policy 1.0.3 for filing a complaint incorrectly states $10 instead of the correct $100. At 9:07 a.m. the court uploads Policy 1.0.4, which includes the corrected fee amount. According to Rule 4, the policy publication time is 9:00 a.m. According to Rule 2 - One Hour Rule and Rule 5 - Top of the Hour Effective Rule, Policy 1.0.3 must remain in effect for one hour, until 10:00 a.m., and Policy 1.0.4 may not become effective until an hour after its publication hour, also 10:00 a.m. Accordingly, the incorrect fee will be published for at least one hour. During this hour, the court may wish stop accepting electronic filings or it may email or call filers who file using the incorrect fee to inform them of the issue. According to Rule 7 - Reliance Timing Rule, applications will become aware of the new fee between 9:45 a.m. and 10:00 a.m. and must begin to use the new fee at 10:00 a.m. At 10:00 a.m., Policy 1.0.3 expires and Policy 1.0.4 becomes effective.

Schema Framework

[98]  All 2GEFS XML Schema are, or are constructed from, XML primitives or building blocks that conform to a consistent set of rules. These rules are documented in the Schema Framework, which is a set of best practices and rules for developing XML Schemas. The Schema Framework ensures that building blocks can be assembled into more complex and versatile XML structures. The Schema Framework also provides version control, unique schema identifiers, support for schema management and maintenance services, and consistent publishing rules for schema discovery and documentation. The Schema Framework is not one schema, but rather a standard and consistent framework of many schemas.

[99]  For example, the Schema Framework provides a standard way to create different Address schemas or a variety of more complex Filing schemas depending on the needs of a particular jurisdiction or the specific requirements of applications within a jurisdiction. This approach serves the needs of different jurisdictions and organizations that have similar but varied requirements. The use of the Schema Framework makes it easier for developers to code around and understand schemas, yet provides the flexibility to serve the varying needs of government, lawyers, vendors, and citizens.

[100]  See http://www.xmllegal.org/SchemaFramework/ for more information.

1.2. Policy:Name
Data Type: xsd:string
go to top

[101]  Policy:Name is a human readable name for the Court Policy. For example, Court Policy for Sacramento County Superior Court, California, USA. There is no special format for Policy:Name value, other than the name must be easily understandable to a human reader.

1.3. Policy:Version
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
MajorVersion11
MinorVersion22

[102]  Policy:Version is the version number for the policy. The format for version numbers is X.Y.Y where X is a major version number and Y.Y is a minor version number. For example, 1.0.0, 1.0.1, 1.0.2 would be appropriate version numbers.

[103]  Version numbers should be incremented by one minor version number for minor revisions and one major version number for major revisions. In case of a major revision, the minor version numbers should both be set to 0. For example, 1.0.0 to 1.0.1 is a minor revision. 1.4.3 to 2.0.0 is a major revision.

[104]  A major revision is a substantial and substantive change to the Court Policy content. For example, the following changes might be considered major revisions: the addition of a new CourtKey (which would signify a new division of the court has been added to the policy), the addition of a new code table, a major revision of the court's fee schedule (especially if it impacts specific document types), or the addition of a new exchange point. A minor revision might be, for example, correction of a typographical error, the addition of a new code value in an existing code table, or changing the amount of a fee in an existing fee schedule.

[105]  Courts are encouraged to pre-publish Policy XML several weeks in advance and no later than three days in advance. This is especially true for major revisions. Pre-publication provides time for applications to implement and test a new policy. While this specification permits publication with as little as one hour notice, only in extreme or emergency situations or where there are minor revisions should courts publish a new policy on such short notice.

[106]  The Policy:Version value should not be confused with the version number of the Policy XML specification. The Policy XML specification version number is determined by the schema's namespace.

1.4. Policy:MajorVersion
Data Type: VersionNumber
go to top

[107]  Policy:MajorVersion is a major version number.

1.5. Policy:MinorVersion
Data Type: VersionNumber
go to top

[108]  Policy:MinorVersion is a minor version number. Two Policy:MinorVersion elements are required.

1.6. Policy:PublicationDate
Data Type: xsd:date
go to top

[109]  Policy:PublicationDate is the date on which a court makes its policy available in a Policy Repository. A policy is not necessarily effective on its publication date. Courts are encouraged to publish Policy XML several weeks in advance of the policy's effective date so that applications can implement and test the policy.

1.7. Policy:PublicationHour
Data Type: Hours
go to top

[110]  Policy:PublicationHour is the top of the hour in which a court makes the policy available in a Policy Repository, provided that the policy is made available in the first forty-five minutes of the hour. The hour is expressed in two-digit military time.

[111]  For example, if a policy is published at 10:32 a.m., then the publication hour would be 10. If the policy is published at 8:43 p.m., then the publication hour would be 20. If the policy is published at 12:10 p.m., then the publication hour would be 12. If the policy is published at 12:10 a.m., then the publication hour would be 00. If the policy is published at 11:12 p.m., then the publication hour would be 23.

[112]  If a policy is published in the last fifteen minutes of an hour, then the publication hour must be the top of the next hour. For example, if a policy is published at 8:50 p.m., then the publication hour must be 21, not 20.

[113]  A policy's publication hour must be at least one hour prior to the policy's effective hour. As a result, a policy is never effective in its publication hour.

1.8. Policy:EffectiveDate
Data Type: xsd:date
go to top

[114]  Policy:EffectiveDate is a date after which the policy is published and on which a policy is in force and applicable to the court. When a policy is effective, the values in it must be used in electronic filings sent to the court. The Policy:PublicationDate and the Policy:EffectiveDate may be the same date. If the publication date and the effective date are the same, then the publication hour must be at least one hour prior to the effective hour.

1.9. Policy:EffectiveHour
Data Type: Hours
go to top

[115]  Policy:EffectiveHour is top of the hour in which a policy is in force and applicable to the court. Effective hour is expressed in two-digit military time. When a policy is effective, the values in it must be used in electronic filings sent to the court.

[116]  Policies can only become effective at the top of an hour. For example, a policy can only become effective at 10:00 a.m. or 1:00 p.m., but not 10:15 a.m. or 1:23 p.m.

1.10. Policy:Contacts
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Contact1unbounded

[117]  Policy:Contacts is a container element for one more more Policy:Contact elements.

1.11. Policy:CourtDivisions
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
CourtDivision1unbounded

[118]  Policy:CourtDivisions is a container element for one or more CourtDivision elements. A single court may have more than one division or department, such as criminal, civil, or traffic. This element provides detailed information about each division or department. See the CourtDivision schema.

1.12. Policy:CodeTables
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
CodeTable1unbounded

[119]  Policy:CodeTables is a container element for one or more Policy:CodeTable elements. A single court is likely to have more than one Policy:CodeTable element for each court and for different court divisions, such as criminal, civil, or traffic. See the CodeTable schema.

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

[120]  Policy:Fees is a container element for one or more Fee elements. See the Fee schema.

1.14. Policy:AcceptedCreditCards
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
CreditCardType1unbounded

[121]  Policy:AcceptedCreditCards is a container element for one or more Policy:CreditCardType elements. If a Policy:CreditCardType value, such as Visa, exists in the policy, then this means the court accepts this type of credit card for payment of electronic filing fees. If a Policy:CreditCardType element does not exist in the policy, then applications should assume that credit cards are not an acceptable form of payment for the court.

1.15. Policy:CreditCardType
Data Type: xsd:string
go to top

[122]  Policy:CreditCardType is a string value for a type of credit card the court will accept. Values for common credit card networks must be used as follows (including spaces and capitalization): (a) Visa, (b) Master Card, (c) American Express, and (d) Discover. Other credit card networks are allowed, even though the network name is not listed in this documentation.

1.16. Policy:MaximumFilingSize
Data Type: xsd:integer
go to top

[123]  Policy:MaximumFilingSize is an integer value for the maximum number of bytes that a court will accept for one Filing XML. The maximum filing size is not the size of individual documents included in the Filing XML. The maximum filing size includes the Envelope XML and the Header XML used to transport the filing. The value must be expressed as the number of bytes, not megabytes or other unit of measure.

1.17. Policy:MaximumDocumentSize
Data Type: xsd:integer
go to top

[124]  Policy:MaximumDocumentSize is an integer value for the maximum number of bytes that a court will accept for a single electronic document within Filing XML. The maximum document size is not the size of the Filing XML. If more than one electronic document is included in Filing XML, the maximum document size is not the combined size of all electronic documents, but rather the size of any individual document. The value must be expressed as the number of bytes, not megabytes or other unit of measure.

1.18. Policy:DelimitExhibits
Data Type: xsd:boolean
go to top

[125]  Policy:DelimitExhibits is a boolean value that expresses whether the court requires exhibits to be separated from the electronic documents with which the exhibits are associated. If the Policy:DelimitExhibits value is true, then exhibits must be delimited. If the Policy:DelimitExhibits value is false, then exhibits must not be delimited. If the Policy:DelimitExhibits element is not present, the default value is false. See the Document schema and Exhibit schema in Filing XML for more information.

1.19. Policy:AcceptedMIMETypes
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
MIMEType1unbounded

[126]  Policy:AcceptedMIMETypes is container element for one or more Policy:MIMEType elements. The court can use this element to state the types of document formats that it will accept.

1.20. Policy:MIMEType
Data Type: MIMETypes
go to top
Attribute(s)typeusefixed/default
DocumentVersionDocumentVersionsrequiredNone
Namespacexsd:stringoptionalNone

[127]  Policy:MIMEType is a MIME type value for an electronic document format. The Policy:MIMEType value is one of the values from the Policy:MIMETypes simpleType. These MIME types represent the most common document formats that would be filed into a court, such as Adobe PDF, Microsoft Word, Corel Word Perfect, or TIFF Images. This element corresponds to the Document:MIMEType element in the Filing XML's Document Schema.

[128]  Policy:MIMEType includes a required attribute DocumentVersion that can have four possible values (a) Final, (b) Draft, (c) Exhibit, or (d) Data File. Final means that the specified MIME type can be used for final documents that are filed with the court. Final documents are documents that are not intended to be edited once they arrive at the court.

[129]  Draft means that the specified MIME type can be used for draft documents filed with the court. Draft documents are documents such as draft orders that are authored by an attorney; delivered to the court; and edited, authored, and filed by a judge or a court clerk.

[130]  Exhibit means that the specified MIME type can be used for exhibits. Exhibits are documents that are often scanned and are therefore only available in TIFF or PDF format.

[131]  Data File means that the specified MIME type can be used for data files. Data files are electronic documents that contain structured data, such as XML data or delimited text.

1.21. Policy:AcceptedEncodings
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Encoding1unbounded

[132]  Policy:AcceptedEncodings is container element for one or more Policy:Encoding elements. A court can use this element to enable or restrict the types of encodings it will accept for filed documents. See the Policy:Encoding element.

1.22. Policy:Encoding
Data Type: Encodings
go to top

[133]  Policy:Encoding is a value that represents the technical way in which a court will receive an electronic document. This element corresponds to the Encoding attribute on the Document:File and Document:DataFile elements in the Filing XML's Document schema.

[134]  The Policy:Encoding element has two possible values (a) Base64 and (b) Link. The element can be included more than once in the Policy:AcceptedEncodings element. The court, therefore, has a choice between accepting (a) base64-encoded documents, (b) documents referenced by links, or (c) both base-64 encoded and linked documents. The following are general rules about base64-encoding and links:

[135]  (a) Neither base64-encoding nor links is 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.

[136]  (b) Base64-encoding is generally simpler than links. Links is more complicated.

[137]  (c) Links performs better than base64-encoding. Links is better for transmitting large documents and filings (over 250-500 KB).

[138]  (d) Sending and receiving applications are encouraged to implement and support both approaches.

[139]  Additional, more detailed documentation on base64-encoding and links can be found in the Document schema.

[140]  There is a subtle difference between the Policy:Encoding element and the Document schema's Encoding attribute. The Policy:Encoding element has two possible values, while the Document schema's Encoding attribute has three possible values. The Encoding attribute in the Document schema includes the values (1) Base64, (2) Link, and (3) Absent. These values in Filing XML and Confirmation XML inform the receiving application whether the document is included as base64 or as a link, or whether the document is absent.

[141]  A document may be absent only in Confirmation XML to report the disposition of a filed document. If a document were absent in Filing XML, then the filing would be rejected. As a result, the Absent value is not relevant in Policy XML. See the Document:File and Document:DataFile elements in the Document schema for more information.

1.23. Policy:AcceptedReplyToProtocols
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
ReplyToProtocol1unbounded

[142]  Policy:AcceptedReplyToProtocols is a container element for one or more Policy:ReplyToProtocol elements. A court can use this element to restrict the types of transmission protocols it will support when it sends Confirmation XML.

[143]  The Header Schema documentation states that confirmations may be sent to ReplyTo addresses using one or more of the following protocols: (a) HTTP, (b) SMTP, (c) Facsimile, or (d) Post. A court is not required, however, to support all of these transmission protocols when sending a confirmation. Policy:AcceptedReplyToProtocols allows a court to state which protocols that it supports when sending confirmations.

[144]  For example, if the court intends to send confirmations only via email, then the court's Policy XML would only include SMTP as a value in one Policy:AcceptedReplyToProtocol element. If the court intends to send confirmations via both email and HTTP, then it would include both SMTP and HTTP in two Policy:AcceptedReplyToProtocol elements. If, for example, the court were to include only SMTP as a value for one Policy:AcceptedReplyToProtocol element, then filing applications may only send email addresses in Header:ReplyTo elements.

[145]  See the Header schema for more information.

1.24. Policy:ReplyToProtocol
Data Type: ReplyToProtocols
go to top
Attribute(s)typeusefixed/default
DeliveryFormatDeliveryFormatsoptionalNone

[146]  Policy:ReplyToProtocol is one of the values from the Policy:ReplyToProtocols simpleType. These protocols can be (a) HTTP, (b) SMTP, (c) Facsimile, or (d) Post. See the Policy:AcceptedReplyToProtocols element and the Header schema.

[147]  The Policy:ReplyToProtocol element includes an attribute DeliveryFormats. The DeliveryFormats attribute applies only to email confirmations and should only be used when the Policy:ReplyToProtocol value is equal to SMTP. There are four possible values for the DeliveryFormats attribute: (a) Links to Information (b) XML as Email Attachment (c) XML and Formatted Document(s) as Email Attachment(s) and (d) Formatted Document(s) Only as Email Attachment(s). The values inform filing applications of the methods the court will support when sending email confirmations.

[148]  Links to Information means that the court will support SMTP confirmations sent to the reply to application as email without attachments. In this situation, one or more hypertext links within the email body will take the recipient to a website where the filing and documents delivered by the filer to the court will be available.

[149]  XML as Email Attachment means that the court will support sending Confirmation XML to the reply to application as an email attachment.

[150]  XML and Formatted Document(s) as Email Attachment(s) means that the court will support sending Confirmation XML and formatted documents to the reply to application, all as email attachments. Formatted documents means a document, such as a Adobe PDF or Microsoft Word document, that the user can open and read in a viewer or other desktop application.

[151]  Formatted Document(s) Only as Email Attachment(s) means that the court will support sending only formatted documents to the reply to application as email attachments. The reply to application will not receive Confirmation XML as an attachment.

[152]  The court may support one or all of these methods of email confirmation. In all of the methods above, the email body may include other information that the recipient can read.

[153]  See the Filing XML's Header schema and the Header:ReplyTo element for more information.

1.25. Policy:UTCOffset
Data Type: xsd:string
go to top

[154]  The Policy:UTCOffset element is used to specify the time zone in which the court resides in UTC format during standard time.

1.26. Policy:UTCOffsetDaylightSavings
Data Type: xsd:string
go to top

[155]  The Policy:UTCOffsetDaylightSavings element is used to specify the time zone in which the court resides in UTC format during daylight savings time.

1.27. Policy:Exchanges
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Exchange1unbounded

[156]   The Policy:Exchanges element is a container element for one or more Policy:Exchange elements. An exchange is an Internet address where types of information exchanges occur to and from a court or justice agency. See the Exchange schema.

1.28. Policy:AssociatedPolicies
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
AssociatedPolicy1unbounded

1.29. Policy:HumanPolicies
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
HumanPolicy1unbounded

[157]   The Policy:HumanPolicies element is a container element for one or more Policy:HumanPolicy elements. A human policy is a human readable policy statement that is not easily encoded into a machine readable format or that does not otherwise have a place in Policy XML. See the HumanPolicy schema.

1.30. Policy:Extensions
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Extension11

[158]   The Policy:Extensions element is a container element for one or more Policy:Extension elements. A Policy:Extension is a generic name/value pair that allows applications to provide machine readable information not included in the Policy XML specification.

1.31. Policy:AssociatedPolicy
Data Type: AssociatedPolicy:AssociatedPolicy
go to top
1.32. Policy:Key
Data Type: Key:Key
go to top

[159]  Policy:Key is a unique identifier for a court policy. This specification provides a standard format for Policy:Key values. The Policy:Key format is the same as the Filing:Key format. See the Key schema.

1.33. Policy:ClerkOfCourt
Data Type: Person:Person
go to top

[160]  Policy:ClerkOfCourt includes name and contact information for the person who is the executive officer or head clerk of the court. See the Person schema.

1.34. Policy:CourtDetails
Data Type: CourtDetails:CourtDetails
go to top

[161]  Policy:CourtDetails contains information about the court's name, location, and contact information.

[162]  The CourtDetails schema includes a CourtDetails:OrganizationKey element and a CourtDetails:CourtKey element. The CourtDetails:OrganizationKey is a unique identifier for an organization. In the context of Policy XML, the organization is a court or other tribunal. There must be a one-to-one relationship between a Court Policy and a Policy:OrganizationKey value.

[163]  For example, the Sacramento Superior Court should have only one unique identifier (i.e., one OrganizaitonKey) and it will should have only one Court Policy. The Sacramento Superor Court's Court Policy may support multiple divisions or departments within the court. Such divisions should be identified using unique CourtDetails:CourtKey values.

[164]  Stated a different way, there is a one-to-one relationship between a Court Policy and an OrganizaitonKey. There is a one-to-many relationship between a Court Policy and CourtKeys. Likewise, there is a one-to-many relationship between an OrganizationKey and CourtKeys.

[165]  There are two places in Policy XML where the CourtDetails schema is used, with an important variation. First, CourtDetails is used by the Policy:CourtDetails element. Second, CourtDetails is used by the CourtDivision:CourtDetails element. In the context of Policy:CourtDetails, the OrganizationKey and the CourtKey values should be the same value. For example, the Superior Court of Sacramento would have an Policy:CourtDetails/CourtDetails:OrganizationKey and a Policy:CourtDetails/CourtDetails:CourtKey with the same value, such as USCASacramentoSuperior.

[166]  In the context of CourtDivision:CourtDetails, a given court division would have different values for OrganizationKey and CourtKey. For example, the Superior Court of Sacramento Small Claims Division would have a CourtDivision:CourtDetails/CourtDetails/OrganizaitonKey value equal to USCASacramentoSuperior and would have a CourtDivision:CourtDetails/CourtDetails/CourtKey value equal to USCASacramentoSuperiorSmallClaims. Similarly, the Sacramento Criminal Traffic division would have the same OrganizationKey value as the Small Claims division, but a different CourtDivision:CourtDetails/CourtDetails/CourtKey value equal to, for example, USCASacramentoSuperiorCriminalTraffic.

[167]  A court may publish multiple versions of its court policy over time. A single court policy may support multiple court divisions. At any given time, however, the court may have only one effective policy for all of its divisions.

[168]  See the CourtDetails schema.

1.35. Policy:CourtDivision
Data Type: CourtDivision:CourtDivision
go to top

[169]   The Policy:CourtDivision element contains information about a division of the court. It includes court details, hours of operation, and contact information for the division. If the information in Policy:CourtDivision is different than in Policy:CourtDetails, Policy:HoursOfOperation, or Policy:Contacts, then applications should assume that the information in Policy:CourtDivision is more specific information that applies to the division. See the CourtDivision schema.

1.36. Policy:Contact
Data Type: Contact:Contact
go to top

[170]   The Policy:Contact element contains contact information such as name, address, phone, and email for people or organizations within the court. See the Contact schema.

1.37. Policy:CodeTable
Data Type: CodeTable:CodeTable
go to top

[171]   The Policy:CodeTable element contains information about a court code table as well as multiple codes. Courts usually have multiple code tables for each court and for different court divisions, such as criminal, civil, or traffic. For example, court code tables often include lists of values for case categories and party roles. See the CodeTable schema.

1.38. Policy:Fee
Data Type: Fee:Fee
go to top

[172]  Policy:Fee contains information about court fees. See the Fee schema.

1.39. Policy:Payment
Data Type: Payment:Payment
go to top

[173]  The Policy:Payment element contains information necessary to pay a court using the Automated Clearing House ('ACH') payments network.

[174]  Generally, there are two models for electronically paying filing fees (a) Offline ACH and (b) Credit Cards. In the Offline ACH model, a service provider submits many filings to a court on behalf of the service provider's customers and then pays the court a lump sum at the end of each business day for the combined total of the day's filings. In this model, ACH is used to transmit the lump sum into the court's bank account. A separate process is then used to reconcile the total cost of all filings and payments deposited into the court's bank account.

[175]  In the alternative Credit Card model, a filing application gathers and passes card information to the court in Filing XML so that the court can charge the filer's credit card and collect payments for individual filings. In this model, service providers do not collect filing fees. Instead, the filing fees are charged at the time of filing to the filer's credit card, payments are collected by the merchant bank, and then the merchant bank settles and deposits the fees into the court's bank account. See the Payment schema for more information on the Credit Card model.

[176]  The Policy:Payment element is optional, as are all of the elements within the Policy:Payment element. There is no requirement to publish payment information in Policy XML if the court does not accept ACH payments or if the court wishes not to do so. If the court prefers to keep its banking information private, then the court should consider publishing ACH information to service providers in a private contract.

1.40. Policy:HoursOfOperation
Data Type: HoursOfOperation:HoursOfOperation
go to top

[177]  Policy:HoursOfOperation contains information about the regular business days and hours on which the court is open, as well as holiday hours. It is possible to use the CourtDivision:HoursOfOperation to specify different hours of operation for each division of the court. The CourtDivision:HoursOfOperation element should only be used if the court division's hours of operation are different than the court's hours of operation. If the CourtDivision:HoursOfOperation is absent, then applications should assume that the court division's hours of operation are the same as the court's hours of operation. See the HoursOfOperation schema.

1.41. Policy:TestCreditCard
Data Type: CreditCard:CreditCard
go to top

[178]  Policy:TestCreditCard contains fake credit card information that can be used to test a court's credit card payment systems. This information should only be present if the court accepts credit cards and wishes to automate the testing process. See the CreditCard schema.

1.42. Policy:Exchange
Data Type: Exchange:Exchange
go to top

[179]  Policy:Exchange contains information about a court exchange. See the Exchange schema.

1.43. Policy:HumanPolicy
Data Type: HumanPolicy:HumanPolicy
go to top

[180]  The Policy:HumanPolicy element is a human readable policy statement. See the HumanPolicy schema.

1.44. Policy:Extension
Data Type: Extension:Extension
go to top

[181]  A Policy:Extension is a generic name/value pair that allows applications to send information not included in the policy specification. See the Policy:Extensions schema.

2. Simple Types

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

Value
text/html
text/plain
text/richtext
text/xml
image/tiff
image/gif
image/jpeg
image/bmp
application/msword
application/octet-stream
application/pdf
Other
2.2. Encodings
Data Type: xsd:string
go to top
Enumeration(s)

Value
Base64
Link
Path
Absent
2.3. ReplyToProtocols
Data Type: xsd:string
go to top
Enumeration(s)

Value
HTTP
HTTPS
SOAP
SOAPS
SMTP
FTP
Facsimile
Post
Media
2.4. DeliveryFormats
Data Type: xsd:string
go to top
Enumeration(s)

Value
Links to Information
XML as Email Attachment
XML and Formatted Document(s) as Email Attachment(s)
Formatted Document(s) Only as Email Attachment(s)
2.5. DocumentVersions
Data Type: xsd:string
go to top
Enumeration(s)

Value
Final
Draft
Exhibit
Data File
2.6. Hours
Data Type: xsd:string
go to top
Enumeration(s)

Value
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2.7. VersionNumber
Data Type: xsd:integer
maxInclusive: 9
minInclusive: 0
go to top

3. Imported Schemas

3.1. Attributes
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Attributes/03/
  
3.2. Address
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Address/03/
  
3.3. CourtDetails
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/CourtDetails/03/
  
3.4. CreditCard
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/CreditCard/03/
  
3.5. Extension
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Extension/03/
  
3.6. Fee
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Fee/03/
  
3.7. Key
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Key/03/
  
3.8. Organization
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Organization/03/
  
3.9. Person
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Person/03/
  
3.10. AssociatedPolicy
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/AssociatedPolicy/01/
  
3.11. CodeTable
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/CodeTable/01/
  
3.12. Contact
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/Contact/01/
  
3.13. CourtDivision
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/CourtDivision/01/
  
3.14. Exchange
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/Exchange/01/
  
3.15. HoursOfOperation
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/HoursOfOperation/01/
  
3.16. HumanPolicy
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/HumanPolicy/01/
  
3.17. Payment
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/Payment/01/
  

4. Change History

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

Added structured copyright and update history.

4.2. 2003-02-23
Editor: Winchel Vincent
go to top

Changed documentation annotations from complexTypes to elements so they would show up in XML Spy.

4.3. 2003-04-29
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Policy/01/
go to top

Changed Court element to CourtDetails. Add CourtDetails module. Added Extensions element and Extension module.

4.4. 2003-06-20
Editor: Winchel Vincent
go to top

Fixed relative path in Attribute import statement.

4.5. 2003-07-01
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/Policy/Test01/
go to top

Copied. Added HoursOfOperation. Added Key schema.

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

Normalized using xmlLegal Normalizer 0.0.9.

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

Copied

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

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

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

Normalized using xmlLegal Normalizer 0.0.9.

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

Updated documentation with explanatory text. Added introductory explanation and links to CA AOC website and schema repositories. Added comments about security, confidentiality, and publication. Added information about the Schema Framework.

4.11. 2004-04-20
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/Test02/
go to top

Copied.

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

Added new Policy:Effective date and documentation. Added Policy:AcceptedCreditCards and Policy:CreditCard elements and documentation. Fixed CodeTable element. Added Policy:AcceptedMIMETypes and MIMEType complexTypes and elements and MIMETypes simpleType.

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

Normalized using xmlLegal Normalizer 0.0.9.

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

Added Policy:AcceptedEncodings and Policy:Encoding elements and Encodings simpleType. Added Policy:AcceptedReplyToProtocols and Policy:ReplyToProtocol elements and ReplyToProtocols simpleType. Eliminated CourtKey schema. Added Policy:CourtDivisions and Policy:CourtDivision elements. Added CourtDivision schema. Changed order of Policy:ClerkOfCourt. Changed Key schema to 02 version. Added documentation stating a new rule in case the effective date and the expiration date are the same, "If a policy effective date is the same as the policy expiration date, this puts applications on notice to check for a new policy each day, not more than once per hour." Added DocumentVersion attribute on Policy:MIMEType to support filing of different file formats for final documents, draft documents, and exhibits. Added Contacts element.

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

Normalized using xmlLegal Normalizer 0.1.0.

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

Made minor typographical changes to documentation. Added headings. Added language about pre-publication of policies. Fixed documentation for Policy:CourtDivision.Clarified that payment information in Policy XML is for ACH an that payment information in Filing XML is done by credit card.

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

Copied. Added DeliveryFormat attribute and DeliveryFormats simpleType. Added "Data File" to DocumentVersions. Added Namespace to MIME Type. Deleted DIME from Encodings. Changed primitive schemas namespace versions from 01 to 02. Clarified documentation on Policy:ExpirationDate. Added Policy:MajorVersion and Policy:MinorVersion.

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

Normalized using xmlLegal Normalizer 0.1.0.

4.19. 2004-09-03
Editor: Winchel Vincent
go to top

Changed MinorVersion to be single element with min and maxOccurs, rather than two elements.

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

Copied.

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

Copied.

4.22. 2005-06-25
Editor: Winchel Vincent
go to top

Changed BuildingBlock schemas to 03 versions. Added Policy:MaximumDocumentSize. Added Policy:DelimitExhibits element. Made minor construct modification to Policy:MinorVersion that does not change validation. Added HumanPolicies element and HumanPolicy schema and element. Added CreditCard schema and TestCreditCard element. Eliminated Policy:ExpirationDate. Changed DocumentVersions attribute on Policy:MIMEType element from optional to required.

4.23. 2005-08-20
Editor: Winchel Vincent
go to top

Added Index:PublicationHour element, Index:EffectiveHour element, and Hours simpleType.

4.24. 2005-09-13
Editor: Winchel Vincent
go to top

Edited schema and documentation to reflect consensus of 2GEFS participants that publication, effective, and expiration dates and time should span one day rather then one hour. Changed Index:PublicationHour to be 00 value only. Changed Index:EffectiveHour to be 07 only.

4.25. 2005-09-23
Editor: Winchel Vincent
go to top

Edited documentation. Changed Policy:CreditCard element name to Policy:CreditCardType.

4.26. 2005-10-05
Editor: Winchel Vincent
go to top

Re-edited documentation and schema to change from One Day rule back to One Hour rule. Made other edits to documentation.

4.27. 2008-10-01
Editor: Schema Generator
go to top

Normalized using xmlSchemaGenerator Normalizer 0.1.5.

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

Copied. Added elements Policy:UTCOffset and Policy:UTCOffsetDaylightSavings. Added schema and elements for AssociatedPolicies and HumanPolicy. Added Path and Absent values to Encodings simpleType. Added new values to ReplyToProtocols simpleType. Created VersionNumber simpleType and made Policy:MajorVersionNumber and Policy:MinorVersionNumber of type VersionNumber.

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