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

Schema Namespace and Documentation
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Header/01/
Schema Prefix
Header
Schema Repository Location
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Header/01/Header.xsd
 
Table of Contents
1. Elements
 Internal
  1.1. Header
  1.2. To
  1.3. CC
  1.4. From
  1.5. ReplyTo
  1.6. URIs
  1.7. People
  1.8. Organizations
  1.9. URI
  1.10. Credentials
  1.11. Username
  1.12. Password
  1.13. Encrypted
  1.14. MessageIdentifiers
  1.15. Date
  1.16. Time
  1.17. Extensions
 External
  1.18. MessageIdentifier
  1.19. Person
  1.20. Organization
  1.21. Extension
2. Simple Types
  2.1. DeliveryFormats
  2.2. Protocols
3. Imported Schemas
  3.1. Attributes
  3.2. Extension
  3.3. Key
  3.4. Organization
  3.5. Person
4. Change History
  4.1. 2003-01-15
  4.2. 2003-07-21
  4.3. 2003-07-21
  4.4. 2003-07-23
  4.5. 2003-07-26
  4.6. 2003-07-27
  4.7. 2003-07-29
  4.8. 2003-07-27
  4.9. 2004-02-29
  4.10. 2004-03-25
  4.11. 2004-04-28
  4.12. 2004-04-29
  4.13. 2004-08-02
  4.14. 2004-08-03
  4.15. 2004-08-05
  4.16. 2004-09-14
  4.17. 2005-06-25
  4.18. 2005-07-10
  4.19. 2005-12-03
  4.20. 2008-09-30
  4.21. 2008-11-13
5. Legal Notices
6. Authors and Contributors

1. Elements

1.1. Header:Header
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
To11
CC01
From01
ReplyTo11
Credentials01
MessageIdentifiers11
Date11
Time11
Extensions01

Introduction

[1]  The purpose of the Header Schema is to provide address and routing information to applications that send, receive, pass through, and reply to Filing XML, Confirmation XML, and Request-Response XML.

[2]  Header is the intended root element of the schema. Header contains information useful for transmitting Filing XML, Confirmation XML, and Request-Response XML contained in the Body element of Envelope XML. Header information is not absolutely needed to accomplish a filing or a request-response transaction. However, certain information, such a Header:ReplyTo and Header:MessageIdentifier, is necessary to send asynchronous confirmations and other response transactions. While Filing XML and Confirmation XML include a globally unique Key element that can be used for tracking, the Header:MessageIdentifier is a potentially more useful means of associating a group of related filings and confirmations.

Envelope XML

[3]  The Header may be used with a 2GEFS Envelope or with a SOAP 1.2 Envelope. The SOAP specification explicitly states that application-specific header information is not defined by the SOAP specification and should be defined by the application. If SOAP is used for transmission, then 2GEFS Header XML must go inside the SOAP Header element as the first child element. SOAP attributes designed to tell SOAP applications whether to understand or forward Header XML elements may be used based on the rules defined for each element in this specification.

[4]  The advantage of using a 2GEFS Envelope is that the Envelope XML, Header XML, and either the Filing XML, Confirmation XML, Request XML, or Response XML, whichever is present, can be constructed and validated as a whole simply with a validating parser. There is no need to learn, use, or build a SOAP toolkit or to interoperate with SOAP created by other SOAP toolkits. The disadvantage of using a 2GEFS Envelope is that developers may not benefit from toolkits and technology add-ons built specifically for SOAP.

Defining Applications

[5]  This specification describes four applications in its examples:

[6]  Sending Application: The sending application is the application that initiates a transaction by sending Filing XML or Request XML. The sending application may also be a receiving application if it receives confirmations or responses, but, because it first sends and then receives, it is named the sending application.

[7]  Receiving Application: The receiving application is the application that receives Filing XML or Request XML and sends back Confirmation XML or Response XML. The receiving application is also a sending application when it sends a confirmation or a response, but, because it first receives and then sends, it is named the receiving application.

[8]  Intermediary Application: An intermediary application is an optional application that passes through transactions and may do additional processing. An intermediary application is both a sending application and a receiving application, but it is never the first sending application and it is never the final receiving application.

[9]  ReplyTo Application: The ReplyTo application is an application that receives Confirmation XML or Response XML from a receiving application. The ReplyTo application may or may not be the original sending application.

Dates and Times in Filing XML and Confirmation XML

[10]  The following table summarizes dates and times in Filing XML and Confirmation XML as those dates and times relate to Header XML.

ElementsFilingConfirmation Synchronous (Received)Confirmation Synchronous (Error)Confirmation Asynchronous (Accepted)Confirmation Asynchronous (Rejected)
Header:Date/TimeMoment of generationMoment of generationMoment of generationMoment of generationMoment of generation
Filing:Date/TimeSender's assertion of when filedN/AN/AN/AN/A
Confirmation:Date/TimeN/AMoment of generationMoment of generationMoment of generationMoment of generation
Confirmation:FilingDate and Confirmation:FilingTimeN/AMirror Filer's assertion of when filedIf available, mirror Filer's assertion of when filed. Otherwise, moment of generationCourt's determination of when filedCourt's determination of when filed

[11]  Moment of generation is the moment the XML is created and then sent, assuming the creation-time and sending-time are close in time (i.e., within seconds or minutes). If the XML is created at a time that is significantly different than when it is sent, then the XML should be edited prior to sending to reflect a date and time as close as possible to the sending date and time.

[12]  All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset.

1.2. Header:To
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
URIs11

[13]  Header:To includes URIs to which the filing or request is being or has been sent. For example, if a sending application sends an Envelope XML with Header XML and Filing XML in it to a URI, then the URI value should be included in the Header:URI element that is a child to the Header:To/Header:URIs element (i.e. Header:To/Header:URIs/Header:URI). The receiving application does not need to understand the Header:To/Header:URIs/Header:URI element, since the receiving application is at the location of the URI. This information is, however, useful for logging and display purposes.

[14]  Header:To information must be forwarded by an intermediary application until it reaches the court. Intermediary applications must add new Header:To/Header:URIs/Header:URI elements as the first child of the Header:URIs element each time the Filing XML or Request XML is forwarded.

[15]  The Filing XML or Request XML should only be sent to one Header:To/Header:URIs/Header:URI at a time. If the Filing XML or Request XML is sent to more than one URI, then the sending application must ensure that, if there are any intermediary applications, only one application forwards the filing or request on to the court. If this rule is not followed, then the same Filing XML or Request XML could be sent twice. It is suggested that the the primary or forwarding URI be sent in the Header:To/Header:URIs/Header:URI element and any secondary or non-forwarding URIs be sent in Header:CC/Header:URIs/Header:URI elements.

[16]  For example, suppose a sending application creates a Filing XML instance document and sends it (a) to a service provider's intermediary server at http://www.one.com/ and (b) to a lawyer's server at http://www.two.com/. The intention is for the service provider to forward the Filing XML to the court's server and for the lawyer's server merely to receive notice that the filing had been made. In this case, the value http://www.one.com/ would go in Header:To/Header:URIs/Header:URI and the value http://www.two.com/ would go in Header:CC/Header:URIs/Header:URI.

[17]  The filing or request may also be CCed to people and organizations via email and facsimile in the Header:CC element. See Header:CC, Header:Person and Header:Organization.

1.3. Header:CC
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
URIs01
People01
Organizations01

[18]  Header:CC includes addresses to which the filing or request is being or has been sent. Header:CC works in the same way as Header:To with respect to URIs, except that inclusion of a URI in Header:CC means that the application at the URI is not meant to forward the Filing XML or Request XML to the court.

[19]  Intermediary applications should understand Header:CC information to ensure that filings and requests are not forwarded after receipt. Applications may, but are not required to, forward Header:CC information.

[20]  The Filing XML and Request XML can be CCed to people and organizations via email and facsimile. See Header:Person and Header:Organization.

1.4. Header:From
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
People01
Organizations01

[21]  Header:From includes the names and contact details of people and organizations from which the filing or request is being or has been sent.

[22]  Header:From does not include a means of specifying a URI because a URI will never be a sending application. However, it is possible to specify a URI in the Header:ReplyTo element. In the case of an asynchronous transaction, for example, a response, such as Confirmation XML, would be sent to the URIs in Header:ReplyTo element.

[23]  Receiving applications do not have to understand information in the Header:From element, but may wish to present such information to users or store it for logging purposes. Intermediary applications must forward Header:From information to the court or other final destination.

1.5. Header:ReplyTo
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
URIs01
People01
Organizations01

Attribute(s)typeusefixed/default
DeliveryFormatDeliveryFormatsoptionalNone

[24]  The Header:ReplyTo element includes addresses to which confirmations or responses must be sent. Each application that wishes to receive a confirmation must add one or more addresses to the Header:ReplyTo element. Intermediary applications may strip the Header:ReplyTo addresses when forwarding on messages to avoid multiple confirmations being sent to multiple ReplyTo applications. If addresses in the Header:ReplyTo element are stripped, then the intermediary application must include its own address in the Header:ReplyTo element and it must forward on confirmations that it receives to the Header:ReplyTo addresses that it stripped.

[25]  Receiving applications must process and reply to all addresses in the Header:ReplyTo element. The exception to this rule is that Policy XML may limit the address protocols that a receiving application supports.

[26]  The four possible address protocols include: (a) URIs for XML over HTTP or SOAP XML over HTTP, (b) Email for XML over SMTP, (c) Facsimile Numbers, and (d) Postal Addresses.

[27]  A receiving application may state in its Policy XML that it only supports, for example, HTTP and SMTP replies (any combination is acceptable). In this example, the receiving application is not required to send replies to facsimile or postal addresses.

[28]  In harmony with the rule that a receiving application must process all addresses (except addresses using protocols the receiving application does not support), a receiving application must process and send initial confirmations to all addresses in the Header:ReplyTo element after it sends a synchronous confirmation. Although this type of confirmation occurs immediately after a synchronous confirmation (which occurs over the same HTTP connection as the filing or request), it is still considered an asynchronous confirmation.

[29]  Header:ReplyTo element has an attribute DeliveryFormat. The DeliveryFormat is a request by the filing application to send a confirmation back to the Header:ReplyTo address in the format indicated by the DeliveryFormat element's value. The DeliveryFormat attribute applies only to SMTP confirmations. Confirmations sent over HTTP must be XML.

[30]  The DeliveryFormat attribute has four possible values: (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).

[31]  Links to Information means that the SMTP confirmation will be sent to the reply to application as email without attachments. One or more links within the email body will take the recipient to the filing and documents delivered by the filer to the court.

[32]  XML as Email Attachment means that the Confirmation or Response XML will be delivered to the reply to application as an email attachment.

[33]  XML and Formatted Document(s) as Email Attachment(s) means that the Confirmation or Response XML and formatted documents will be delivered 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.

[34]  Formatted Document(s) Only as Email Attachment(s) means that only formatted documents will be delivered to the reply to application as email attachments. The reply to application will not receive XML as an attachment.

[35]  In all of the situations above, the email body may include other information that the recipient can read.

1.6. Header:URIs
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
URI1unbounded

[36]  Header:URIs is a container element for one or more Header:URI elements.

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

[37]  Header:People is a container element for one or more Header:Person elements.

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

[38]  Header:Organizations is a container element for one or more Header:Organization elements.

1.9. Header:URI
Data Type: xsd:string
go to top
Attribute(s)typeusefixed/default
ProtocolProtocolsrequiredNone

[39]  Header:URI contains an address to which a filing or confirmation is being or has been sent.

[40]  The Protocols attribute is required to specify the type of URI. The available protocols are: HTTP, HTTPS, SOAP over HTTP (herein SOAP), SOAP over HTTPS (herein SOAPS), FTP, SMTP, Facsimile, postal mail, and bar coded paper (fax or post).

1.10. Header:Credentials
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Username11
Password11
Encrypted11

[41]  Header:Credentials is a container element for username and password information.

1.11. Header:Username
Data Type: xsd:string
go to top

[42]  Header:Username is the username of the person or application sending the Filing XML or Request XML. If the Header:Encrypted element is set to false, then the Header:Username value must be unencrypted. If the Header:Encrypted element is set to true, then the Header:Username value must be encrypted.

1.12. Header:Password
Data Type: xsd:string
go to top

[43]  Header:Password is the password of the person or application sending the Filing XML or Request XML. If the Header:Encrypted element is set to false, then the Header:Password value must be unencrypted. If the Header:Encrypted element is set to true, then the Header:Password value must be encrypted.

1.13. Header:Encrypted
Data Type: xsd:boolean
go to top

[44]  The Header:Encrypted element is a boolean value that indicates, when true, that the Header:Username and Header:Password are encrypted and, when false, that the Header:Username and Header:Password are unencrypted. For security reasons, the Header does not include information about the encryption algorithm or encryption key. It is assumed in a single-key cryptosystem that the parties exchanging information will know the encryption algorithm and the encryption key.

[45]  The purpose of encrypting the Header:Username and the Header:Password is to avoid sending and storing the information in the clear. It must be stressed, however, that when using a single-key cryptosystem the sending party, the receiving party, or any other party that knows or can discover the encryption algorithm and the encryption key could easily forge, discover, or later manipulate the information.

[46]  Applications wishing to use two-key cryptosystems or public key infrastructure should use the W3C XML Signature specification or the W3C XML Encryption specification.

1.14. Header:MessageIdentifiers
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
MessageIdentifier1unbounded

[47]  The Header:MessageIdentifiers element is a container element for one or more Header:MessageIdentifier elements. A message identifier is used so that ReplyTo applications (which may also be sending applications) and intermediary applications can match a confirmation or response with a filing or request. Each Header:MessageIdentifier must be globally unique. As a result, the Header:MessageIdentifier is defined as a Key:Key element. See the Key Schema.

[48]  A sending application must include one Header:MessageIdentifier value. An intermediary application and a receiving application may either add a new Header:MessageIdentifier or rely on the sending application's Header:MessageIdentifier. All applications that receive and forward or reply to (i.e., send a confirmation or response) must copy and send all Header:MessageIdentifier elements in the headers that the application constructs.

1.15. Header:Date
Data Type: xsd:date
go to top

[49]  Header:Date is the date on which the Header XML and its Envelope XML are created.

[50]  All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset.

1.16. Header:Time
Data Type: xsd:time
go to top

[51]  Header:Time is the time on which the Header XML and its Envelope XML are created.

[52]  All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset.

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

[53]  Header:Extensions is a container element for one or more Header:Extension elements.

1.18. Header:MessageIdentifier
Data Type: Key:Key
go to top

[54]  Header:MessageIdentifier is a unique identifier for a new message. Even if intermediary applications and receiving applications add additional message identifiers, the first Header:MessageIdentifier value is a unique identifier for a set of related filing and confirmation or request and response transactions. Each Header:MessageIdentifier must be globally unique. As a result, the Header:MessageIdentifier is defined as a Key:Key element. See the Key Schema.

1.19. Header:Person
Data Type: Person:Person
go to top

[55]  Sending applications may populate the Header:Person element with any information in the Person Schema. However, sending and receiving applications are only required to process and send names and email addresses. Sending and receiving applications may process postal addresses and fax numbers, if the application has the ability to forward filings in these ways. Sending applications should include email addresses, fax numbers, and postal addresses in the Header:Person element only if the application intends for the Filing XML to be sent to the address or fax number.

[56]  Filings sent to postal addresses or fax machines may apply a stylesheet to the Filing XML so that the information in the filing is human-readable.

1.20. Header:Organization
Data Type: Organization:Organization
go to top

[57]  Sending applications may populate the Header:Organization element with any information in the Organization Schema. However, sending and receiving applications are only required to process and send names and email addresses. Sending and receiving applications may process postal addresses and fax numbers, if the application has the ability to forward filings in these ways. Sending applications should include email addresses, fax numbers, and postal addresses in the Header:Organization element only if the application intends for the Filing XML to be sent to the address or fax number.

[58]  Filings sent to postal addresses or fax machines may apply a stylesheet to the Filing XML so that the information in the filing is human-readable.

1.21. Header:Extension
Data Type: Extension:Extension
go to top

[59]  A Header:Extension is is a generic name/value pair that allows applications to send information not included in the Header Schema. See Extension Schema.

2. Simple Types

2.1. 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.2. Protocols
Data Type: xsd:string
go to top
Enumeration(s)

Value
HTTP
HTTPS
SOAP
SOAPS
SMTP
FTP
Facsimile
Post
Media

3. Imported Schemas

3.1. Attributes
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Attributes/03/
  
3.2. Extension
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Extension/03/
  
3.3. Key
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Key/03/
  
3.4. Organization
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Organization/03/
  
3.5. Person
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Person/03/
  

4. Change History

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

Initial Draft.

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

Normalized using xmlLegal Normalizer 0.0.9.

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

Copied.

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

Copied.

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

Changed Extension namespace and import location to reflect move of Extension to Building Block folder.

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

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

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

Copied.

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

Changed ConfirmationIdentification to ConfirmationIdentifier. Added ConfirmationIdentifier element to Header content model (previously unintentionally omitted).

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

Made typographical changes. Flagged issue regarding unique identifiers to Header:Identifier.

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

Copied.

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

Added elements and documentation to make Header:MessageIdentifier unique and allow multiple Header:ReplyTo addresses. Changed Header:CC, Header:From, and Header:ReplyTo to sequence and optional. Made Header:Credentials optional. Made Header:From required (to offset potential lack of credentials). Made Header:To required. Added Key schema. Changed Header:MessageIdentifier to be of type Key:Key. Deleted Header:MessageIdentifier complexType. Deleted Header:ConfirmationIdentifier as it is unnecessary. Rewrote documentation so that it applies to both filing/confirmation and request/response transactions. Previously, the documentation was slightly different.

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

Normalized using xmlLegal Normalizer 0.1.0.

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

Copied.

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

Changed Header:ReplyTo from optional to required. Changed Header:From from required to optional.

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

Normalized using xmlLegal Normalizer 0.1.0.

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

Copied.

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

Copied. Changed Attributes, Extensions, Key, Organization, and Person to 03 versions.

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

Documentation.

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

Copied.

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

Normalized using xmlSchemaGenerator Normalizer 0.1.5.

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

Copied. Added Protocol attribute with enumerated values to the Header:URI element.

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