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

Schema Namespace and Documentation
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/HumanPolicy/01/
Schema Prefix
HumanPolicy
Schema Repository Location
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/02/HumanPolicy/01/HumanPolicy.xsd
 
Table of Contents
1. Elements
 Internal
  1.1. HumanPolicy
  1.2. CourtKeys
  1.3. CourtKey
  1.4. Key
  1.5. Name
  1.6. Description
  1.7. Paragraph
  1.8. Vocabulary
  1.9. Category
  1.10. Address
  1.11. RequirementLevel
 External
2. Simple Types
  2.1. CategoryLevels
  2.2. RequirementLevels
3. Imported Schemas
  3.1. Attributes
4. Change History
  4.1. 2005-06-26
  4.2. 2005-06-26
  4.3. 2008-10-01
  4.4. 2008-11-13
5. Legal Notices
6. Authors and Contributors

1. Elements

1.1. HumanPolicy:HumanPolicy
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
CourtKeys11
Key01
Name11
Description11
Category01
Address01
RequirementLevel01

Introduction

[1]  Policy XML is intended to include policy information that is machine readable. There are times when machine readable policy either cannot be encoded in the elements available in the Policy XML specification or policy is difficult to encode for machine consumption. For occasions when policy cannot be encoded for machine consumption, this specification provides elements to express human readable policy.

Specification

[2]  HumanPolicy is the intended root element of the schema. HumanPolicy must include the following four child elements (a) CourtKeys, (b) Name, (c) Description, and (d) RequirementsLevel. HumanPolicy may contain three additional child elements (1) Key, (2) Category, and (3) Address.

1.2. HumanPolicy:CourtKeys
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
CourtKey1unbounded

[3]  HumanPolicy:CourtKeys is a container element for one or more HumanPolicy:CourtKey elements. The HumanPolicy:CourtKeys element is used to associate the policy statement with one or more CourtDetails:CourtKey values. See HumanPolicy:CourtKey element.

1.3. HumanPolicy:CourtKey
Data Type: xsd:string
go to top

[4]  HumanPolicy:CourtKey provides a means to associate the human readable policy statement with a CourtDetails:CourtKey. The CourtDetails:CourtKey value is a unique identifier that corresponds to a division of a court. A HumanPolicy:CourtKey value must match a CourtDetails:CourtKey value or the court's CourtDetails:OrganizationKey value. If the HumanPolicy:CourtKey value matches the court's CourtDetails:OrganizationKey value, then the policy statement applies to every division of the court. If the HumanPolicy:CourtKey value matches one or more Court:Details:CourtKey values, then the policy statement applies only to those matching court divisions.

1.4. HumanPolicy:Key
Data Type: xsd:string
go to top

[5]  HumanPolicy:Key is a unique identifier for the policy statement. If there are more than one HumanPolicy elements, then all HumanPolicy:Key values must be unique.

1.5. HumanPolicy:Name
Data Type: xsd:string
go to top

[6]  HumanPolicy:Name is a short, descriptive name for the policy statement.

1.6. HumanPolicy:Description
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Paragraph1unbounded

[7]  HumanPolicy:Description is a detailed description that explains the policy. HumanPolicy:Description has one child element, HumanPolicy:Paragraph, that must occur once and may occur an unlimited number of times. A single paragraph or multiple paragraphs may be used to describe the policy.

1.7. HumanPolicy:Paragraph
Content Model: sequence
Mixed: true
go to top
Child Element(s)minOccursmaxOccurs
Vocabulary0unbounded

[8]  HumanPolicy:Paragraph is a single paragraph that makes up part of the HumanPolicy:Description. HumanPolicy:Paragraph is defined as mixed content and may contain zero or an unlimited number of HumanPolicy:Vocabulary elements. A paragraph can be text only or it can include various vocabulary sprinkled within it.

1.8. HumanPolicy:Vocabulary
Data Type: xsd:string
go to top

[9]  HumanPolicy:Vocabulary is an element that marks-up an important word or series of words, such as a name or a defined term, in a paragraph. The global attributes Class and Type can be used to modify the HumanPolicy:Vocabulary element. The Class attribute functions in the same way as the HTML class attribute and should be used to convey style information for the vocabulary. The Type attribute may also be used to further define or modify the generic HumanPolicy:Vocabulary element.

1.9. HumanPolicy:Category
Data Type: xsd:string
go to top
Attribute(s)typeusefixed/default
LevelCategoryLevelsrequiredNone

[10]  HumanPolicy:Category provides a means to categorize policy statements. HumanPolicy:Category includes a required Level attribute. The Level attribute may be one of six values Level1, Level2, Level3, Level4, Level5, or Level6. The Level attribute provides the ability to create a hierarchy of categories and subcategories without creating either a recursive element or additional fixed elements necessary for a non-recursive structure. For this type of categorization mechanism to function properly, policy statements must occur in the XML document in logical order based on category level.

[11]  For example, policy statements must occur with the following levels in document and logical order: Level1[1], Level2[1.1], Level2[1.2], Level1[2], Level2[2.1], Level2[2.2], where Category 1 has two subcategories that correspond to the first three levels in the example (i.e., Level1[1], Level2[1.1], Level2[1.2]) and where Category 2 has two subcategories that correspond to the second three levels in the example (i.e., Level1[2], Level2[2.1], Level2[2.2]).

[12]  The values Level2 through Level6 must always occur after a lower level. For example, Level2 may only occur after Level1. If the Level attribute is always set to Level1, then this means there is no categorization.

1.10. HumanPolicy:Address
Data Type: xsd:anyURI
go to top

[13]  HumanPolicy:Address is a URL that points to a resource with additional information. If there are multiple resources that contain additional information, then those resources must be consolidated into one resource referenced by HumanPolicy:Address.

1.11. HumanPolicy:RequirementLevel
Data Type: RequirementLevels
go to top

[14]  HumanPolicy:RequirementsLevel value is a required element that states whether the policy is required, recommended, optional, or informational. The values MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119 (http://www.ietf.org/rfc/rfc2119.txt). The value Information is not defined by RFC 2119. The Information value means that the policy statement is for informational purposes only and is not a required, recommended, or optional policy.

2. Simple Types

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

Value
Level1
Level2
Level3
Level4
Level5
Level6
2.2. RequirementLevels
Data Type: xsd:string
go to top
Enumeration(s)

Value
MUST
MUST NOT
SHOULD
SHOULD NOT
MAY
Information

3. Imported Schemas

3.1. Attributes
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Attributes/03/
  

4. Change History

4.1. 2005-06-26
Editor: Winchel Vincent
go to top

Created

4.2. 2005-06-26
Editor: Winchel Vincent
go to top

Normalized using xmlLegal Normalizer 0.1.1.

4.3. 2008-10-01
Editor: Schema Generator
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Policy/Test05/HumanPolicy/01/
go to top

Copied.

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

Copied.

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