4091 lines
184 KiB
XML
4091 lines
184 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xsd:schema targetNamespace="http://xml.house.gov/schemas/uslm/1.0"
|
|
xmlns="http://xml.house.gov/schemas/uslm/1.0"
|
|
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
|
xmlns:dcterms="http://purl.org/dc/terms/"
|
|
elementFormDefault="qualified"
|
|
attributeFormDefault="unqualified"
|
|
version="1.0.18">
|
|
|
|
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
|
|
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
|
|
<xsd:import namespace="http://purl.org/dc/terms/"
|
|
schemaLocation="http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd"/>
|
|
<xsd:import namespace="http://www.w3.org/1999/xhtml"
|
|
schemaLocation="http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd"/>
|
|
|
|
<xsd:annotation>
|
|
<xsd:documentation>
|
|
<![CDATA[
|
|
|
|
======================================================================
|
|
*United States (Federal) Legislative Model (USLM)*
|
|
======================================================================
|
|
|
|
** Objective **
|
|
|
|
This schema provides a general schema for modeling the United States
|
|
Code, including all titles and appendices. It is designed to model
|
|
both existing and future titles. The intent is to support XML data
|
|
delivery, publishing, editing, and automated processing of the titles
|
|
and appendices.
|
|
|
|
The schema in intended to be extensible to model bills, resolutions,
|
|
statutes, amendments, and other legislative documents.
|
|
|
|
This schema is not intended to model executive branch or judicial
|
|
branch documents, except as such exist in notes and appendices.
|
|
|
|
** Understanding this Schema **
|
|
|
|
This schema is designed in several layers. The best way to learn the
|
|
schema is to first understand the fundamental building blocks and then
|
|
to build your understanding one layer at a time. The order of
|
|
declaration and definitions is generally the best order to learn it as
|
|
well.
|
|
|
|
This schema is designed following a "Venetian Blind" design pattern.
|
|
This means that each element type is defined separately and a separate
|
|
element declaration is created. This pattern maximizes the reusability
|
|
of the schema.
|
|
|
|
** Overriding Principles **
|
|
|
|
* The general derivation hierarchy is from most abstract to most
|
|
concrete.
|
|
* Terminology chosen for abstract elements is purposefully designed
|
|
to minimize conflict with existing terminology by avoiding well-
|
|
established terms.
|
|
* Terminology chosen for concrete elements is purposefully designed
|
|
to map very closely to existing terminology.
|
|
* The overall tag set is kept as small as possible without
|
|
compromising semantic richness.
|
|
* The schema is more permissive
|
|
than is absolutely necessary. As this schema must support legacy
|
|
documents, a looser rather than tighter contract is required to be
|
|
enforced by the schema. In general, the abstract layer is intended
|
|
to support the variation extremes while the concrete layer is
|
|
intended to support modern practices.
|
|
* Consistency with XHTML naming conventions and practices is
|
|
maximized.
|
|
* Care has been taken to avoid reinventing mark-up for areas, such as
|
|
tables or formulas, where perfectly good mark-up has already been
|
|
designed.
|
|
* The overall structure has been designed to create a readable
|
|
document without any unnecessary redirection.
|
|
* All text shown in the printed or published document is regular
|
|
text, not contained within attributes or to be
|
|
generated from attribute data. Rather, the resulting text is shown
|
|
in the content.
|
|
* Attributes are used to contain metadata or normalized forms of
|
|
text content. (i.e. normalized numeric values) The general flow of
|
|
data is from the content to the attributes rather than the other
|
|
way around.
|
|
* The schema is designed for editing documents as well as for complete
|
|
documents. This means that the "empty document" situation is handled and
|
|
validates as a complete and correct document.
|
|
* This schema has tentatively been designed for use with relational
|
|
database mapping and shredding tools.
|
|
|
|
** General Definitions **
|
|
|
|
Jurisdictions:
|
|
* United States Federal Government - us
|
|
|
|
Languages:
|
|
* English Language - eng
|
|
|
|
** Primitives **
|
|
|
|
The purpose of the primitives is to provide the fundamental building
|
|
blocks out of which everything can be built. The primitives are a
|
|
minimal set of basic type definitions along with a corresponding set
|
|
of element declarations.
|
|
|
|
At the very top of the derivation tree is the "BaseType" and two
|
|
closely related derivatives "BaseBlockType" and "BaseContentType". These types
|
|
are primarily to provide base types for all the attributes. They are defined as
|
|
abstract types and therefore cannot be instantiated.
|
|
|
|
All other types derive from these types, by way of either restriction
|
|
and/or extension. The
|
|
terminology chosen for the primitive layer has been selected to
|
|
describe, in the most general of terms, the fundamental building
|
|
blocks. Care has been taken to avoid using terms which already have an
|
|
established meaning within U.S. legislation and to avoid implying
|
|
too much meaning or structure beyond the primitive nature of the
|
|
elements.
|
|
|
|
** Common Core **
|
|
|
|
The common core defines the basic structure of a legislative document.
|
|
It is a very abstract and general model intended to be flexible enough
|
|
to handle the widest variations likely to be encountered.
|
|
|
|
It is possible, using the common core, along with the primitives defined above
|
|
and the generics defined below, to model any U.S legislation, albeit
|
|
abstractly. The terminology chosen has been selected to be familiar
|
|
without conflicting with any well-established meanings in use
|
|
for U.S. legislation.
|
|
|
|
** Structural Building Blocks **
|
|
|
|
The structural building blocks are assemblies of elements which are
|
|
used to define the common core. Rather than defining individual elements,
|
|
they define groups of elements which are placed together to define
|
|
the content of elements in the common core. The building blocks are
|
|
largely responsible for taking care of the flexible notes model and
|
|
the underlying versioning model.
|
|
|
|
** Generics **
|
|
|
|
The generics provide fundamental elements necessary to model any
|
|
type of document. These elements fit within the common core, but are
|
|
not themselves a part of it. In general, these elements model common
|
|
structures like paragraphs, images, columns, and line breaks.
|
|
|
|
The generics exist to complete the common core without clouding the
|
|
core with basic functions that don't contribute the legislative nature
|
|
of the schema. The terminology chosen has been selected to be familiar
|
|
everyday terms for common concepts. Care has been taken to not
|
|
override any well-established meaning in use for U.S. legislation.
|
|
|
|
** Synonyms **
|
|
|
|
The synonyms are used to give familiar and comfortable
|
|
terms to the most commonly used elements in modern legislation.
|
|
These synonyms are more meaningful tags used as equivalent
|
|
substitutes for the more abstract tags defined in the common core. As
|
|
they are defined as synonyms rather than within a rigid content
|
|
model, care must be taken to avoid using them in ways beyond their
|
|
original intent and harming the semantic value of XML.
|
|
|
|
** Naming Elements **
|
|
|
|
There are three attributes for defining names for elements:
|
|
|
|
* The @id attribute is an immutable identity, one that is
|
|
not changed once it is assigned. Therefore, it should not reflect any
|
|
aspect of the element that is subject to change, such as an
|
|
assigned number. The preferred algorithm for generating the @id attribute
|
|
value is to use a GUID (Globally Unique IDentifier)
|
|
generator that guarantees uniques in all space and time. The @id
|
|
should be given a simple "id" prefix.
|
|
|
|
* The @name attribute is assigned a simple, short name that identifies
|
|
a child element within the context of its parent. The @name attribute
|
|
is used when the element is not uniquely defined within
|
|
its parent by using the element name alone. For some elements, such
|
|
as sections and other levels, the @name attribute value can be a function
|
|
of time. This is because the section or level can be renumbered and this
|
|
number will be reflected in the chosen @name attribute value. For these
|
|
cases, the @name attribute value can be parameterized and evaluated
|
|
whenever a document is requested for a specific point-in-time. Two
|
|
parameters can be specified: {num}, which is the current normalized value
|
|
of the element, and {index}, the 1-based index position of the element
|
|
within its parent.
|
|
|
|
* The @temporalId attribute is assigned a changeable, human-meaningful,
|
|
identifier. Like the @name attribute, the @temporalId will vary with time.
|
|
For this reason, the @temporalId is computed
|
|
each time a document is extracted from the repository, based on the
|
|
point-in-time requested, rather than being statically stored with
|
|
the text in the repository. The @temporalId is specified to be nominally
|
|
unique within the document that the element belongs. The @temporalId is
|
|
composed by concatenating the @temporalId of the element's parent, if
|
|
existing (or the parent element's name if the @temporalId does not exist),
|
|
"_", and the element's <num> @value. For example, paragraph 2 of
|
|
subsection (a) of section 1 should have the @temporalId of "s1_a_2".
|
|
|
|
** Referencing Model **
|
|
|
|
All references are modeled as relative URLs. References are made to
|
|
a logical rather than a physical hierarchy that starts always from the
|
|
jurisdiction and reaches down to individual provisions within a bill,
|
|
Resolution, or other Legislation. References do not predict or
|
|
expect any particular document partitioning. It is the intent of the
|
|
URL handler to map the logical hierarchy to any specific physical
|
|
hierarchy.
|
|
|
|
The highest level of the hierarchy is always the
|
|
jurisdiction code, specified using the ISO 3166-1 country code and
|
|
optionally followed by a dash and a lower level jurisdiction code.
|
|
For the U.S. Federal Government, the jurisdiction code is "us".
|
|
|
|
Lower levels of the hierarchy should either be a year with an
|
|
optional modifier, or an abbreviated prefix and an assigned numeric
|
|
designation, separated with the "/" in a hierarchy. For instance,
|
|
Title 5 is expressed as "/us/usc/t5" while Pub. L. 111-314 is expressed
|
|
as "/us/pl/111/314".
|
|
|
|
When a URL is extended to within a document, the document hierarchy is
|
|
expressed in an abbreviated form as in "/us/usc/t5/s101" or
|
|
"/us/pl/111/314/s1".To build this URL, append
|
|
the reference to the document + "/" + the element name with each
|
|
dashes changed to a "/". So a reference to "s3-2-1" in
|
|
"/us/pl/111/314" becomes "/us/pl/111/314/s3/2/1".
|
|
|
|
A language-neutral reference does not include a language code. To
|
|
create a reference to a specific language version of the document,
|
|
include a language identifier at the nominal document level following
|
|
a "!" symbol. For instance, to specify a reference to
|
|
section 101 the English version of title 51, the
|
|
reference would be "/us/usc/t51!eng/s101".
|
|
|
|
To make a reference to a version that is operational at a specific
|
|
point in time, include a date specification at the nominal document
|
|
level following a "@" symbol ("at" the time of). For instance, to
|
|
specify a reference to section 101 of Title 51 on 1 February,
|
|
2013, the reference would be "/us/t51@2013-02-01/s101".
|
|
|
|
When including both a language and a time specification, place
|
|
the language specification ahead of the time specification. For
|
|
instance to combine both examples above, the result would be
|
|
"/us/t51!eng@2013-02-01/s101".
|
|
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Simple Types -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="DateSimpleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The date simple type unifies both date and time formats and allows
|
|
a date to be specified as either a day or a time in a day. This is
|
|
to allow situations where the law becomes effective based on another
|
|
time zone.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:union memberTypes="xsd:date xsd:dateTime"/>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="OccurrenceSimpleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The occurrence simple type specifies which occurrence is affected
|
|
by an action when amending. An occurence can be either a positive integer
|
|
or a value from the choice enumeration such as "all" for
|
|
all occurrences or "last" for the last occurrence.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:union memberTypes="xsd:positiveInteger ChoiceEnum"/>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="ShortStringSimpleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A simple string with not more than 32 characters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:maxLength value="32"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="MediumStringSimpleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A simple string with not more than 128 characters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:maxLength value="128"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="LongStringSimpleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A simple string with not more than 1024 characters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:maxLength value="1024"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Enumerations -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="ChoiceEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The choice enumeration is used to enumerate some textual values for
|
|
use with the occurrence simple type defined above.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="all"/>
|
|
<xsd:enumeration value="none"/>
|
|
<xsd:enumeration value="first"/>
|
|
<xsd:enumeration value="last"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="PropertyTypeEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The property type enumeration allows a property to be given a
|
|
type specification. If the @type attribute is not specified, then
|
|
the default type is "string".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="string"/>
|
|
<xsd:enumeration value="number"/>
|
|
<xsd:enumeration value="token"/>
|
|
<xsd:enumeration value="boolean"/>
|
|
<xsd:enumeration value="text"/>
|
|
<xsd:enumeration value="date"/>
|
|
<xsd:enumeration value="url"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="SetTypeEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The set type enumeration is used allows a set of properties, grouped
|
|
using the <set> element, to be given a type specification. If the
|
|
@type attribute is not specified, then the default type is "bag".
|
|
|
|
The type values are inspired by the Resource Descriptor Framework
|
|
(RDF).
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="bag">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "bag" is an unordered but homogeneous collection of
|
|
properties or sets.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="seq">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "seq" (sequence) is an ordered and homogeneous sequence of
|
|
properties or sets.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="grp">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "grp" (group) is a heterogeneous collection of properties
|
|
or sets.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="alt">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An "alt" (alternatives) is a homogeneous collection of properties or sets of which one is selected at any one time.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="res">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "res" is a resource, such as a person, place, or thing and
|
|
the properties enclosed within the set describe it.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="StatusEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The status enumeration is used to specify the state of a provision
|
|
during the period of time defined by the @startPeriod and the
|
|
@endPeriod attributes attached to the same element or hierarchically
|
|
defined above.
|
|
|
|
Typically, the status enumeration is applied to the <section> level
|
|
or lower, but the model is general enough that it can be applied
|
|
anywhere in the level hierarchy. A <section> will progress through a
|
|
series of statuses, starting out as "proposed" in a bill, becoming
|
|
"pending" when the bill is enacted, "operational" on
|
|
the commencement date, and then later possibly "repealed".
|
|
|
|
It is quite possible that stages in this sequence
|
|
might be skipped. For instance, a section might be repealed before
|
|
it ever becomes operational or it might never be repealed.
|
|
If the status is not specified, then a section is assumed to be
|
|
"operational".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="proposed"/>
|
|
<xsd:enumeration value="withdrawn"/>
|
|
<xsd:enumeration value="cancelled"/>
|
|
<xsd:enumeration value="pending"/>
|
|
<xsd:enumeration value="operational"/>
|
|
<xsd:enumeration value="suspended"/>
|
|
<xsd:enumeration value="renumbered"/>
|
|
<xsd:enumeration value="repealed"/>
|
|
<xsd:enumeration value="expired"/>
|
|
<xsd:enumeration value="terminated"/>
|
|
<xsd:enumeration value="hadItsEffect"/>
|
|
<xsd:enumeration value="omitted"/>
|
|
<xsd:enumeration value="notAdopted"/>
|
|
<xsd:enumeration value="transferred"/>
|
|
<xsd:enumeration value="redesignated"/>
|
|
<xsd:enumeration value="reserved"/>
|
|
<xsd:enumeration value="vacant"/>
|
|
<xsd:enumeration value="crossReference"/>
|
|
<xsd:enumeration value="unknown">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "unknown" status indicates that the status is not known.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="ActionTypeEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The action enumeration is used to specify the action being
|
|
undertaken by an amendment, or, in the case of multiple actions,
|
|
the actions as well as the order in which they are to be performed.
|
|
|
|
There are two basic sets of actions: those for law and those for
|
|
proposed law. Pre-enactment stage amendments will use the "insert" and
|
|
the "delete" actions when amending rather than the other actions
|
|
intended for modifying enacted law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="enact">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "enact" action enacts a law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="add">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "add" action adds a provision to existing law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="amend">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "amend" action modifies an existing provision in the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="substitute">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "substitute" action replaces an existing provision in the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="renumber">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "renumber" action changes the number of an existing provision in the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="repeal">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "repeal" action repeals an existing provision in the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="insert">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "insert" action adds text to a proposed provision to the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
<xsd:enumeration value="delete">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The "delete" action removes text from a proposed provision to
|
|
the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:enumeration>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="PositionEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The position enumeration is used with references found within
|
|
amendments when it is necessary to specify a position relative to an item
|
|
rather than when referencing the item itself.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="start"/>
|
|
<xsd:enumeration value="before"/>
|
|
<xsd:enumeration value="inside"/>
|
|
<xsd:enumeration value="after"/>
|
|
<xsd:enumeration value="end"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="OrientationEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The orientation enumeration is used to specify how an item should be
|
|
oriented in the printed form. The orientation can be specified
|
|
for any content item or for any appendix item, including a
|
|
schedule.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="portrait"/>
|
|
<xsd:enumeration value="landscape"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:simpleType name="NoteTypeEnum">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Notes can be placed inline, as footnotes at the end of the page,
|
|
as end notes as the end of document, or U.S. Code notes. By default,
|
|
notes are inline
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:restriction base="xsd:NMTOKEN">
|
|
<xsd:enumeration value="inline"/>
|
|
<xsd:enumeration value="footnote"/>
|
|
<xsd:enumeration value="endnote"/>
|
|
<xsd:enumeration value="uscNote"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Attribute Groups -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="XmlSpecialAttrs">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
This attribute groups is similar to the same attribute group defined
|
|
in the XML.xsd schema file, except it omits the "id" attribute.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute ref="xml:base"/>
|
|
<xsd:attribute ref="xml:lang"/>
|
|
<xsd:attribute ref="xml:space"/>
|
|
<!-- <xs:attribute ref="xml:id"/> -->
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="IdentificationGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The identification group of attributes is used to add an identity to
|
|
an element. All elements use the identification group, and all
|
|
attributes are optional. In general
|
|
|
|
- An @id is an immutable GUID assigned to an item at its birth.
|
|
- A @name is a time variant local name, scoped to its parent.
|
|
- An @temporalId is a time variant name, scoped to the document.
|
|
- An @identifier is an item variant URL, scoped globally.
|
|
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="id" type="xsd:ID" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @id attribute should always be assigned an immutable
|
|
(non-changing) value. If the item is subject to renaming or
|
|
renumbering, then the @id attribute should not reflect any part
|
|
of the changeable part. This is to allow the @id to be long
|
|
lasting without causing confusion should the item be renamed or
|
|
renumbered.
|
|
|
|
The @id should be prefixed with "id" and followed by a GUID that
|
|
is guaranteed to be globally unique across both time and space.
|
|
|
|
As an "xsd:ID", the identity must be ensured to be unique in the
|
|
document - and it is a good idea that it be guaranteed globally
|
|
unique. As the @id is immutable, it is a good identity with which
|
|
to associate external information to the item.
|
|
|
|
If an item is deleted and later a similarly named item is
|
|
created, then the new item should be assigned a newly generated
|
|
identity as it is not related to the earlier item.
|
|
|
|
The @id attribute is optional, but recommended for all elements
|
|
which will contain any other identity attributes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="name" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @name attribute is a local name that is intended to reflect
|
|
the current identity of the element in a human-readable way. This
|
|
means that the @name may need to be recomputed based on the
|
|
temporal state of a document or according to the temporal
|
|
specification in a requesting URL.
|
|
|
|
To support temporal parameterization, the @name can be specified
|
|
as a formula with parameters in the name which are intended to be
|
|
resolved by the temporal engine at request time. Two parameters
|
|
are supported:
|
|
|
|
- {num} - use the current @value of the associated <num>.
|
|
- {index} - use the index position (1-based) of the element
|
|
calculated against other elements of the same type at the same
|
|
level.
|
|
|
|
The @name should be stored as a formula and returned as resolved
|
|
for specific point-in-time return results.
|
|
|
|
The @name is used to compose the @temporalId attribute (if
|
|
desired) and is used when resolving references.
|
|
|
|
When an element does not have a @name attribute, it is
|
|
identified by the element name. When an element does have a
|
|
@name attribute, then the @name takes precedence over the element
|
|
name.
|
|
|
|
Some examples of @name attribute values:
|
|
|
|
* "subject" - a property named "subject".
|
|
* "s{num}" - a numbered section. Use the @value of the child
|
|
<num> corresponding to the temporal specification to evaluate
|
|
the formula.
|
|
* "proviso{index}" - Use the 1-based index number of the
|
|
proviso, calculated against other <proviso> elements within
|
|
the parent element. For example, "the second proviso"
|
|
corresponds to "proviso2".
|
|
|
|
The @name attribute is optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="temporalId" type="MediumStringSimpleType"
|
|
use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @temporalId attribute is a name, scoped to the document,
|
|
that is intended to reflect the current identify of the element
|
|
in a human-readable way. This means that the @temporalId may need
|
|
to be recomputed based on the temporal state of a document or
|
|
according to the temporal specification in a requesting URL.
|
|
|
|
A @temporalId is intended to be scoped to the document as a whole
|
|
while the @name is scoped to its immediate parent. The
|
|
@temporalId is built as an "_" separated hierarchy of @name
|
|
or, in the absence of an @name, element names. However, in a
|
|
couple cases, the levels of the hierarchy are suppressed. First
|
|
of all, the <main> level is suppressed when calculating any
|
|
@temporalId contained within. Secondly, when dealing with
|
|
sections which are numbered as a sequence without regard to
|
|
the upper levels, then the upper levels are suppressed from the
|
|
computation of the @temporalId.
|
|
|
|
Some examples:
|
|
|
|
* "s2" - section to in the main part of the document
|
|
* "schedule_s2" - section 2 in the schedule
|
|
* "s2_1_proviso_a" - paragraph a of the proviso in subsection 1
|
|
of section 2.
|
|
* "P2_D1" - division 1 of part 2 in the main part of the
|
|
document
|
|
|
|
The @temporalId attribute is optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="identifier" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @identifier attribute to specify the URL context of the
|
|
element. Typically, the @identifier will be established on the
|
|
root element or on any element, such as a <quotedStructure> or
|
|
<quotedText> element, that changes the context.
|
|
|
|
The @identifier attribute is optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
|
|
<xsd:attributeGroup name="ClassificationGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The classification group is used to further refine the element
|
|
type and to specify any exception cases for styling the element
|
|
when presented in the printed form. The @role attribute is inspired
|
|
by the new @role attribute defined in support of WAI-ARIA for use
|
|
in XHTML. Both the @class and the @style attributes are inspired by
|
|
the identically named HTML attributes and their behavior is the
|
|
same. All elements use the classification group.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="role" type="ShortStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @role attribute to provide further refinement to an
|
|
element's type. This is particularly useful when defining a
|
|
refinement of an element from the abstract set. Another possible
|
|
use is to use the customary local name for an element whenever
|
|
the element name is not a complete match. For example, if the
|
|
customary name for an "explanation" is "summary", then the
|
|
element can be expressed as <explanation role="summary">.
|
|
|
|
There can be thought of as rough equivalence between an element
|
|
of a base class with a @role attribute and a derived class in the
|
|
schema, although this equivalence is not explicit. For example
|
|
<level role="division"> is roughly equal to <division>.
|
|
|
|
When transforming XML to HTML, the @role attribute should be
|
|
appended to the element name using an "_" underscore and used
|
|
as the first value in the HTML @class attribute. If desired,
|
|
the proposed XHTML @role attribute can be computed as either the
|
|
XML @role attribute or, in the absence of the XML @role
|
|
attribute, the XML element name. For example:
|
|
|
|
<level role="division">
|
|
=> <div role="division" class="level_division">
|
|
|
|
<division>
|
|
=> <div role="division" class="division">
|
|
|
|
This approach is easily reversible.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="class" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @class attribute corresponds to the @class attribute in
|
|
HTML. It can be used to specify presentation characteristics
|
|
of an element that are not specified by the element name and
|
|
the @role attribute. For example, the @class attribute can be
|
|
used to specify the presence or absence of the ending separator.
|
|
|
|
Like the HTML @class attribute, multiple class values can be
|
|
specified in a space separate list.
|
|
|
|
Whenever USML XML is transformed into HTML, the first class name
|
|
should always correspond to the element name + the @role
|
|
attribute. Subsequent values should be taken as the value of the
|
|
@class attribute. It is possible that additional @class values
|
|
may be necessary in the HTML rendition, to support editing
|
|
operations. These should be filtered by the transform that
|
|
creates the USLM XML.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="style" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @style attribute is used to specify CSS attributes that
|
|
override the default styles defined for an element or an element
|
|
class. The current loose-leaf publication standards should be
|
|
specified using an external style sheet and the use of the @style
|
|
attribute should be reserved for exception cases where the
|
|
default presentation must be overridden.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="AnnotationGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The annotations group is used to specify annotations with elements
|
|
that are outside of the published content. As attributes, only
|
|
limited text values should be associated using this mechanism. This
|
|
mechanism should never be used for notes to be published. All
|
|
elements use the annotation group.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="note" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @note attribute should be the primary mechanism for recording
|
|
simple text notes to be associated with elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="alt" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @alt attribute should be used to provide an alternative
|
|
description of the element. For use with WCAG 2.0 and other
|
|
accessibility initiatives.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="meta" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @meta attribute should be used to associate metadata
|
|
information with the element for search and other used. How this
|
|
attribute is used is not prescribed by the schema.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="misc" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @misc attribute is provided for future use.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="draftingTip" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @draftingTip is for internal use.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="codificationTip" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @codificationTip is for internal use by the OLRC.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="DescriptionGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The description group is used to record information that will be
|
|
used to describe an element, primarily for use in a table of
|
|
contents or an index. The description group can be used for
|
|
statements, the preamble, levels, and appendices including
|
|
schedules. In addition, the description group is an integral
|
|
part of a TOC item. All attributes are optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="title" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @title attribute is used to specify the text describing the
|
|
element in a table of contents or index. It must be a simple text
|
|
string and should consist of fewer than 40 or so characters -
|
|
although this is not enforced.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="brief" type="LongStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @brief attribute is an alternate method for providing a
|
|
a longer description of an element, limited to 1024 characters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="sortOrder" type="xsd:integer" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @sortOrder attribute is used to specify a sorting order for
|
|
a list of items, when that sort order is not the document
|
|
sequence. The @sortOrder value must be specified as a positive
|
|
integer. This attribute should rarely be used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="ReferenceGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The reference group is used to create references to other items.
|
|
These items can be items within the document, items in other documents,
|
|
or entire other document. See the reference specification for how
|
|
reference URL references are constructed. <property> and
|
|
<reference> elements can use the reference group.
|
|
|
|
All attributes are optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="href" type="xsd:anyURI" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @href attribute is used to specify references to external
|
|
documents or items in documents. The value must always be
|
|
specified as a relative URL conforming to the reference
|
|
specification.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="idref" type="xsd:IDREF" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @idref attribute is used to specify references to internal
|
|
elements within the same document. The @idref is specified as
|
|
the value of the @id attribute of the element being referenced.
|
|
As in HTML, there is an equivalence between an @href specified
|
|
as href="#{id}" and idref="{id}". However, the @idref attribute
|
|
is preferred for internal references.
|
|
|
|
If the @idref points to a <ref> element, then the referencing
|
|
element builds on top of that reference, acquiring its attributes
|
|
as default values (which may be overridden by local values). This
|
|
is a recursive structure; an element may, through the @idref
|
|
attribute, point to an <ref> element which itself builds on
|
|
another <ref> element, and so on. This is to support the complex
|
|
referencing sometimes found in legislation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="portion" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @portion attribute is used, in conjunction with the @idref
|
|
attribute, when only a portion of the referenced item is being
|
|
affected. The value of @portion is an additional part to append
|
|
to the URL, with a "/" separator to identify the item affected.
|
|
Do not include a leading "/" in the @portion value.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="AmendingGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The amending group is used to point to items being amended. See the
|
|
reference specification for how reference URL references are
|
|
constructed. The amending group should only be used on references
|
|
or actions within amending instructions.
|
|
|
|
All attributes are optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="pos" type="PositionEnum" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @pos attribute is used to specify a location relative
|
|
to the item being referenced. The @pos is intended primarily
|
|
for used with amending instructions.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="posText" type="MediumStringSimpleType"
|
|
use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @posText attribute is used to specify text to be used as the
|
|
context for the @pos attribute.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="posCount" type="xsd:positiveInteger" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @posCount attribute is used to specify the number of
|
|
occurrences of the @posText to seek out when establishing the
|
|
context.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="LinkGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The link group is used to reference external documents to be
|
|
embedded in a document. The link group can be used for either
|
|
appendices or for images. The @src attribute is optional, but
|
|
should always be used for images.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="src" type="xsd:anyURI" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @src attribute is a URL that points to an item to be included
|
|
in the published document. Unlike an @href attribute, a @src
|
|
attribute can be any normal URL and can be relative or absolute.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="ValueGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The value group is used to keep a normalized value. In some cases
|
|
the value is recorded as text content and the normalized form is
|
|
stored in the @value attribute. The @type attribute is usually used
|
|
to type the value. The value group can be used for <property> and
|
|
<num> elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="value" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @value attribute is used when there is a single value.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="startValue" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @startValue attribute is used for the lower end of a value
|
|
range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="endValue" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @endValue attribute is used for the upper end of a value
|
|
range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="NoteGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The note group is used to place and categorize notes, either
|
|
singularly or as groups. The @type attribute is used for placement
|
|
while the @topic attribute is used for categorization.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="type" type="NoteTypeEnum" use="optional" default="footnote">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Set the @type attribute to "footnote" to indicate that
|
|
the notes contained should be shown in the footnotes at
|
|
the end of the page or to "endnote" to indicate the
|
|
notes contained should be shown at the end of the
|
|
document. If not specified, "footnote" is assumed.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="topic" type="MediumStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Set the @topic attribute to a string value in order
|
|
to categorize the note or group of notes. An open,
|
|
but enumerated, list of string values should be used.
|
|
Using a fixed list of values will better aid in
|
|
categorization of notes later.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="DateGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The date group is used to keep a normalized date. Both normal dates
|
|
and date + times can be stored. The format for all dates is either
|
|
the xsd:date or xsd:datetime formats which are ISO 8601 based. The
|
|
date group can be used with <property>, <date>, and <note> elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="date" type="DateSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @date attribute is used for a single date value.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="startDate" type="DateSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @startDate attribute is used for the starting date of a date
|
|
range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="endDate" type="DateSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @endDate attribute is used for the ending date of a date
|
|
range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="VersioningGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The versioning group is used to record dates and statuses of
|
|
different versions of various elements. These attributes define
|
|
the versioning model for USLM. In general, when an item is
|
|
versioned, different versions of an element will exist alongside
|
|
one another with different time periods and statuses defined.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="startPeriod" type="DateSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @startPeriod attribute is the earliest date that a particular
|
|
version applies to. The @startPeriod is not necessarily the
|
|
effective date. It's merely the earliest date that the particular
|
|
version of the text should be returned in point-in-time
|
|
calculations.
|
|
|
|
The @startPeriod works with the @endPeriod which defines that
|
|
last date that a specific version applies to. Together, the
|
|
@startPeriod and the @endPeriod define a period of time that the
|
|
version applies to. This version may be in states such as
|
|
pending, operational, partially commenced, suspended, or even
|
|
repealed.
|
|
|
|
If the @startPeriod is not specified, then all past time is
|
|
assumed.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="endPeriod" type="DateSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @endPeriod attribute is the last date that a specific version
|
|
of the text should be returned in point-in-time calculations.
|
|
|
|
If the @endPeriod is not specified, then all future time is
|
|
assumed.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="status" type="StatusEnum" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @status attribute is used to show the status of a version
|
|
of provision. This attribute works with the @startPeriod and the
|
|
@endPeriod and applies to the period of time defined by these
|
|
attributes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="partial" type="xsd:boolean" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @partial attribute is used, in conjunction with the
|
|
@status attribute to indicate that the status is not fully
|
|
applied.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="ActionGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The action group is used to describe amending actions found within
|
|
amending formulas. A single amending formula may consist of
|
|
a sequence of actions.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="type" type="ActionTypeEnum" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @type attribute describes the type of action being taken.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="occurrence" type="OccurrenceSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @occurrence attribute describes which occurrence of item in question
|
|
should the action take effect on.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="actionDate" type="DateSimpleType"
|
|
use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @actionDate attribute specifies the date upon which the
|
|
action is to be applied.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:attributeGroup name="CellGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The cell group is used to describe a cell in a tabular structure
|
|
found within legislation.
|
|
|
|
The @colspan and @rowspan attributes are inspired by the HTML
|
|
attributes of the same name. Consequently, the names are specified
|
|
as all lower-case which is a minor inconsistency to the naming
|
|
convention used for all other attributes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attribute name="colspan" type="xsd:integer" use="optional"
|
|
default="1">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @colspan attribute, like the corresponding HTML attribute,
|
|
defines the number of columns a column tag must span.
|
|
If this attribute is not set, then the column span is one.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="rowspan" type="xsd:integer" use="optional"
|
|
default="1">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @rowspan attribute, like the corresponding HTML attribute,
|
|
defines the number of rows a specific column tag must span.
|
|
If this attribute is not set, then the row span is one.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attribute name="leaders" type="ShortStringSimpleType" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @leaders attribute specifies whether leaders should be
|
|
shown either trailing or following the text content. The
|
|
character included as the value is the character used to render
|
|
the leaders.
|
|
|
|
Use the CSS text-align character to position the text. If the
|
|
text is aligned to the left, then the leaders will show to the
|
|
right and if the text is aligned to the right, then the leaders
|
|
will show to the left.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Primitive Definitions -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:annotation>
|
|
<xsd:documentation>
|
|
<![CDATA[
|
|
|
|
** Primitive Definitions **
|
|
|
|
There are five basic primitive types. All elements are defined to be
|
|
one of these five basic types. In addition to types derived from these
|
|
five basic types, there are also five abstract element declared
|
|
directly from these types. These elements can be used, in some cases,
|
|
for when the more specific cases do not apply. In those cases, the
|
|
primitive types can be used along with the @role attribute to create
|
|
new informal types.
|
|
|
|
*** Basic Rules ***
|
|
|
|
* A marker contains nothing within it.
|
|
* An inline contains text, or any inline structure including
|
|
inline, ref, or marker.
|
|
* A block contains any block structure including block, content,
|
|
or property.
|
|
* A content (block) contains text or any block or other content.
|
|
|
|
]]></xsd:documentation>
|
|
|
|
</xsd:annotation>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="BaseType" abstract="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The base type defines the most general element, specifying the
|
|
attributes which can be found on all elements - specifically
|
|
attributes belonging to the identification, classification, and
|
|
annotation groups.
|
|
|
|
The base type is defined as an abstract type and elements cannot
|
|
be declared based on it.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:simpleContent>
|
|
<xsd:extension base="xsd:string">
|
|
<xsd:attributeGroup ref="XmlSpecialAttrs"/>
|
|
<xsd:attributeGroup ref="IdentificationGroup"/>
|
|
<xsd:attributeGroup ref="ClassificationGroup"/>
|
|
<xsd:attributeGroup ref="AnnotationGroup"/>
|
|
<xsd:attributeGroup ref="DescriptionGroup"/>
|
|
<xsd:attributeGroup ref="VersioningGroup"/>
|
|
<xsd:anyAttribute namespace="##other" processContents="lax"/>
|
|
</xsd:extension>
|
|
</xsd:simpleContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="BaseBlockType" abstract="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The base block type is a variant of the base type, but having a
|
|
content structure to support block level children - elements
|
|
but no text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attributeGroup ref="XmlSpecialAttrs"/>
|
|
<xsd:attributeGroup ref="IdentificationGroup"/>
|
|
<xsd:attributeGroup ref="ClassificationGroup"/>
|
|
<xsd:attributeGroup ref="AnnotationGroup"/>
|
|
<xsd:attributeGroup ref="DescriptionGroup"/>
|
|
<xsd:attributeGroup ref="VersioningGroup"/>
|
|
<xsd:anyAttribute namespace="##other" processContents="lax"/>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="BaseContentType" abstract="true" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The base content type is a variant of the base type, but having
|
|
a very open content model including text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:attributeGroup ref="XmlSpecialAttrs"/>
|
|
<xsd:attributeGroup ref="IdentificationGroup"/>
|
|
<xsd:attributeGroup ref="ClassificationGroup"/>
|
|
<xsd:attributeGroup ref="AnnotationGroup"/>
|
|
<xsd:attributeGroup ref="DescriptionGroup"/>
|
|
<xsd:attributeGroup ref="VersioningGroup"/>
|
|
<xsd:anyAttribute namespace="##other" processContents="lax"/>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="MarkerType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The marker type is a restriction of the base type to an element
|
|
without content.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<!-- No content -->
|
|
<xsd:simpleContent>
|
|
<xsd:restriction base="BaseType">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:length value="0"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:restriction>
|
|
</xsd:simpleContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="InlineType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The inline type is an extension of the base type to text content or
|
|
other inline elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseContentType">
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="marker"/>
|
|
<xsd:element ref="inline"/>
|
|
<xsd:element ref="note"/>
|
|
</xsd:choice>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="BlockType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The block type is a extension of the base type to content
|
|
consisting of only elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##targetNamespace"/>
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="ContentType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The content type is a broad base type allowing any content.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseContentType">
|
|
<xsd:sequence>
|
|
<xsd:any minOccurs="0" maxOccurs="unbounded" namespace="http://www.w3.org/1999/xhtml ##targetNamespace" processContents="strict"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="orientation" type="OrientationEnum" use="optional"
|
|
default="portrait">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @orientation attribute is used to specify a "landscape"
|
|
orientation for the published form. This is primarily used
|
|
for schedules or for tables.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Primitive Declarations -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:element name="marker" type="MarkerType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <marker> element is a primitive element to be used to mark or
|
|
denote a spot in the text. It can be used in the <content> areas or
|
|
anywhere else where an <inline> element is expected. The <marker>
|
|
element contains no text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="inline" type="InlineType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <inline> element is a primitive element to be used within
|
|
<content> areas or within any other areas which can accept
|
|
inline content.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="block" type="BlockType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <block> element is a primitive element to be used anywhere
|
|
where <block> elements are permitted including within <content>
|
|
elements or anywhere where <block> elements have been explicitly
|
|
permitted.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="content" type="ContentType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <content> element is a primitive element to be used anywhere
|
|
where a very general content model is desired, including within
|
|
other <content> elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Core Definitions -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
|
|
Key:
|
|
|
|
* <tag> ... </tag> is the enclosing tag
|
|
* <child> is a required child
|
|
* [<child>] is an optional child
|
|
* [<child>]? is a sequence of zero or one child
|
|
* [<child>]* is a sequence of zero or more children
|
|
* <child1>|<child2> is either child1 or child2
|
|
* [<child1>|<child2>] is either child1 or child2 or neither
|
|
* [<child1>|</child2>]* is a sequence of zero or more child1s or
|
|
child2s in no particular pattern
|
|
|
|
Basic Model:
|
|
|
|
* <doc>[<meta>][<main>][<appendix>]*</doc>
|
|
* <meta>[<set>|<property>]*</meta>
|
|
* <toc>[<heading>][<subheading>][<layout>|<tocItem>]*</toc>
|
|
* <tocItem>[<heading>][<subheading>][<layout>]*</tocItem>
|
|
* <main>[<property>|<toc>|<preamble>|<statement>|<note>|
|
|
<enactingFormula>|<level>|<crossHeading>]*<main>
|
|
* <statement>[{text}|<content>|<inline>|<ref>|<marker>|<p>|
|
|
<notes>]*</statement>
|
|
* <level><num>?<heading>?<subheading>?<notes>?[<instruction><notes>?|
|
|
<content><notes>?|<toc>?[<text>|<level>|
|
|
<crossheading>|note]*]]</level>
|
|
* <num>{text}</num>
|
|
* <heading> can contain text, inline, ref, marker
|
|
* <appendix> can contain content
|
|
* <notes> can contain text, note, inline, marker
|
|
* <note> can contain text, inline, ref, marker
|
|
* <instruction> can contain text, action, quotedText,
|
|
quotedStructure (<instruction> is abstract)
|
|
* <action> can contain text, ref
|
|
* <quotedContent> can contain text, statement, main, level, num,
|
|
heading, ref, date, attachments, attachment, notes, note
|
|
* <ref>[{test}|<inline>|<marker>]*</ref>
|
|
* <date>[{text}|<inline>|<ref>|<marker>]*</date>
|
|
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
|
|
<xsd:complexType name="LawDocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The law doc type is the core root element type for all document that
|
|
contain law - either proposed or enacted.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:element ref="meta">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
All documents start with a meta area containing properties about
|
|
the document. The information contained within this area is not
|
|
official text in the document and should not be published other
|
|
than as editorial notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="main" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The primary part of the document is the main area. This contains
|
|
the bulk of the document including any hierarchical levels,
|
|
sections, table of contents, etc.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="block">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A block container, usually for signatures and signing dates.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="appendix">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
In addition to the main part of the document, a document
|
|
may have one or more appendices such as schedules or
|
|
explanatory memorandums/notes. These appendices can
|
|
either be inline documents or the can be external
|
|
referenced documents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="schemaVersion" type="xsd:string" use="optional" />
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="GenericDocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The generic doc type is the core type for generic loosely structured
|
|
documents.
|
|
|
|
Documents using legislative structures and subject to amending,
|
|
either locally or by an external jurisdiction, should not use this
|
|
format.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:element ref="meta">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
All documents start with a meta area containing properties about
|
|
the document. The information contained within this area is not
|
|
official text in the document and should not be published other
|
|
than as editorial notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The primary part of the document is the content area. This
|
|
can contain a basic generic document structure.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="appendix" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
In addition to the content part of the document, a document may have
|
|
one or more appendices.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="MetaType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The meta type is a core level container for metadata relating to the
|
|
document. The metadata is not part of the official text of the
|
|
document and should not be displayed in the printed text, other
|
|
than in editorial comments.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:any namespace="http://purl.org/dc/elements/1.1/" processContents="lax">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Core elements defined by the Dublin Core may be used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:any>
|
|
<xsd:any namespace="http://purl.org/dc/terms/" processContents="lax">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Terms defined by the Dublin Core may be used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:any>
|
|
<xsd:element ref="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Properties are added to the metadata to record varying
|
|
aspects of the document. In addition to generic
|
|
properties, there are defined derivatives of the
|
|
property type that can also be used, for things like
|
|
the document type and document number.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="set">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Properties can be grouped into sets. These sets can
|
|
be used to represent something like a series of events,
|
|
a person, or another other object related to the
|
|
document.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="PropertyType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The property core type is used to record metadata about a document.
|
|
Properties usually are found in the meta area and are not an official
|
|
part of the document. However, properties can also be found in the
|
|
official text when they are defined there. In that case, the text
|
|
content of the property is the official text in the document and
|
|
a normalized date, value, or reference attribute might also be defined.
|
|
|
|
In some cases, specific elements are derived from the property type
|
|
with more descriptive names. In that case, the descriptive name is
|
|
the equivalent of the @name attribute on a core property element.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="InlineType">
|
|
<xsd:attributeGroup ref="DateGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A property can represent a date or a date range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attributeGroup ref="ValueGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A property can represent a value or a value range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attributeGroup ref="ReferenceGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A property can represent a pointer to either an external
|
|
document or an element within the document.
|
|
|
|
A ref can be used to create a pointer to an endnote or a
|
|
footnote. In that case, the ref text will be the endnote or
|
|
footnote indicator as seen in "<ref idref="fn000001">†</ref>"
|
|
where the dagger is the indicator. An endnote or footnote
|
|
reference should always use the @idref attribute to point to
|
|
an endnote or a footnote within the document.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attribute name="type" type="PropertyTypeEnum" use="optional" default="string">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
By default, a property is a string. The @type attribute is used to define
|
|
an alternate property type. The attributes of the Reference Group are used
|
|
when the @type is set to "url". The attributes of the Value Group are used
|
|
when the @type is set to "string", "number", "token", or "boolean" or the
|
|
@type is not set. The attributes of the Date Group are used when the @type
|
|
is set to "date".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="SetType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The set type is the core type for a group of properties. Property
|
|
sets are found within the meta area only. Sets can contain other
|
|
sets as well as properties.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:any namespace="http://purl.org/dc/elements/1.1/" processContents="lax">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Properties defined by the Dublin Core may be used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:any>
|
|
<xsd:element ref="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A set can contain 0 or more properties.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="set">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A set can contain 0 or more sets.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
<xsd:attribute name="type" type="SetTypeEnum" use="optional" default="bag">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
By default, the properties in a set are a simple "bag" of
|
|
properties, known as an unordered set. However, a set of
|
|
properties can also be typed using the @type attribute,
|
|
choosing values from the set type enumeration.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="TocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The TOC core type is used to define a table of contents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:group ref="HeadingStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A table of contents may have a heading.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="tocItem">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A table of contents can have 0 or more items.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="layout">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The items in a table of contents can be arranged in
|
|
a tabular fashion by surrounding the items in a layout.
|
|
When a layout is specified, use <column> elements
|
|
within each <tocItem> to indicate specific columns.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="generate" type="xsd:boolean" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @generate attribute is used to denote table of contents
|
|
that are to be auto-generated. The TOC generator should
|
|
generate any TOC for which a stub TOC exists (an empty
|
|
<toc> element) or generate/regenerate any TOC with a
|
|
@generate attribute with a value of "true".
|
|
|
|
Any TOC generated by a TOC generator and stuffed into the
|
|
<toc> element should include the @generate attribute with
|
|
a value of "true".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="TocItemType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The TOC item core type is an item in a table of contents. Items
|
|
can be nested to create a hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:choice>
|
|
<xsd:sequence>
|
|
<xsd:group ref="HeadingStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An item in a table of contents may have a heading.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:element ref="tocItem" minOccurs="0"
|
|
maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An item in a table of contents can have child items when
|
|
it is a level in the hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
<!-- MaxOccurs is set to 3 to allow three columns in the TOC -->
|
|
<xsd:element ref="content" maxOccurs="3">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
When an item is the lowest level in the hierarchy,
|
|
use the <content> element to describe the text to show.
|
|
If the text is arranged in columns, use <column>
|
|
elements to denote each column.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="MainType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The main core type is the container for the main part of the
|
|
document. The content model defines the various aspects in a very
|
|
flexible model allowing arbitrary ordering. This is due to a
|
|
limitation in XML schemas. The general model allows for properties,
|
|
table of contents, and statements to be at the top of the document,
|
|
the preamble or enacting formula in the middle, the levels and
|
|
cross-heading below that, and notes interspersed anywhere.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="BlockType">
|
|
<xsd:sequence>
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
In addition to placing properties in the <meta> area,
|
|
properties can also be found in the main container.
|
|
Elements derived from the core <property> and defined
|
|
within the property substitution group can also be
|
|
used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="block">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Blocks derived from the core <block> property and
|
|
included in the block substitution group, such as
|
|
approval signatures, can be placed in the main
|
|
container.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="statement">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Statements or elements derived from the core
|
|
<statement> property and included in the statement
|
|
substitution group can be placed in the main
|
|
container.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="toc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <main> body of the document may have a table of
|
|
contents. Typically this will be generated. The
|
|
model permits multiple <toc> elements, but this is
|
|
only due to limitations with XML schemas (XSD 1.0).
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:group ref="NoteStructure"/>
|
|
</xsd:choice>
|
|
<xsd:group ref="PreambleStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The preamble structure, which includes the simple
|
|
enacting formula, is optional to allow for its removal in
|
|
enacted law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="LevelStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The document is permitted to be empty to allow for the
|
|
case when the document is newly created and still in a
|
|
drafting state.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
</xsd:sequence>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="StatementType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The statement core type is used for most of the provisions that
|
|
begin a legislative document. Preambles, enactment formulas, and
|
|
other starting provisions are all derivations of statements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseContentType">
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="marker">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A statement can contain markers.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A statement can contain inline elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="block">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A statement can contain blocks.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Interspersed between levels in a hierarchical level context
|
|
can be placed such as an opening <chapeau>,
|
|
closing <continuation>, or a <proviso>. It is also
|
|
possible to have interstitial content modeled as
|
|
<containment>, although the need should be very rare.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A statement can contain content elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A statement can be composed of hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="PreambleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The preamble core type is the optional container for recitals and
|
|
the enacting formula. In most modern Bills, the preamble is omitted
|
|
and a single standalone enacting formula is used instead.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:group ref="HeadingStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <preamble> can, in some cases, begin with a heading.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="RecitalStructure" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <preamble> is made up of a series of recitals.
|
|
Recitals typically begin "Whereas,".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:element ref="enactingFormula" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
When the <preamble> is present, the enacting formula
|
|
will end the preamble in a Bill.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="LevelType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The level core type is the basic element in the primary document
|
|
hierarchy. Levels are used to represent items ranging from Title,
|
|
Subtitle, etc, down to subsubclauses. Typically, a derived synonym
|
|
which more closely describes the level type will be used rather
|
|
than the abstract.
|
|
|
|
There are some level types found in U.S. Code which
|
|
do not have a defined name or number. For example, see the
|
|
undesignated heading levels in Title 12, Chapter 7.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:group ref="NumStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <level> is usually numbered. However, in a few cases,
|
|
typically preliminary sections or with item lists, this
|
|
may not be the case.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="HeadingStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <level> generally has a heading, but this is not
|
|
required.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="TocStructure" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
It is uncommon, but possible, that a table of contents
|
|
may be found within the level hierarchy. Typically, this
|
|
<toc> will be manually defined rather than generated.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="LevelStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The primary part of a <level>. This may not exist in
|
|
cases where the level has been repealed, omitted, spent,
|
|
or otherwise removed and a simple note has been left
|
|
behind.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="NumType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The numType is used to surround the numeric designation given
|
|
to a hierarchical level and other items in a document. The
|
|
<num> element should surround the complete text of the number
|
|
including any preceding prefix and any decoration and punctuation.
|
|
This is to allow the complete text to be property displayed in
|
|
the published form.
|
|
|
|
Numbers can be used for either single values or for number ranges.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="InlineType">
|
|
<xsd:attributeGroup ref="ValueGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @value attribute to record a normalized value of
|
|
the <num> content. When the text content represents a
|
|
range of values, use the @beginValue and @endValue
|
|
attributes to record the range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="HeadingType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The heading type is used to define heading and subheadings for
|
|
levels and other structured items. Often a heading will follow
|
|
a number.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="ContentType"> </xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="InstructionType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The instruction type is used to describe an amendment or a
|
|
modification. It contains a sequence of one or more actions which
|
|
may have quoted text or quoted structures associated. When multiple
|
|
actions are present, they are executed in the order in which they
|
|
appear when the amendment or modification is applied.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseContentType">
|
|
<xsd:sequence>
|
|
<xsd:element ref="ref">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Specify at least one item to be amended or modified.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:element ref="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Various inline elements can be used.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="marker">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Various markers can be used. This includes line breaks
|
|
that can be included for formatting purposes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
<xsd:sequence maxOccurs="4">
|
|
<xsd:element ref="action" maxOccurs="4">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The action describes an atomic operation within the
|
|
amendment.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:choice minOccurs="0">
|
|
<xsd:element ref="level" minOccurs="1" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A list of amendments may be enumerated, typically
|
|
as items.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="quotedText">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A quoted text string may be associated with an
|
|
action (by position) as part of the processing
|
|
action.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="quotedContent">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A quoted structure may be associated with an
|
|
action (by position) as part of the processing
|
|
action.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
</xsd:sequence>
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="ActionType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An action type is used to describe an amendment action in terms that
|
|
a computer program can explain. It surrounds the human readable text
|
|
of the amendment action and adds @href, @pos, and @action attributes
|
|
to describe the same information for programmatic evaluation.
|
|
|
|
When an amendment contains multiple actions, they are to be executed
|
|
sequentially in the order in which they appear.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="InlineType">
|
|
<xsd:attributeGroup ref="ReferenceGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @href and @idref attributes along with the
|
|
Amending Group attributes to describe what is being
|
|
affected.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attributeGroup ref="AmendingGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @pos and other attributes to describe what is being
|
|
affected.
|
|
|
|
The attributes in the amending group should only be used
|
|
for references or actions within an amending instruction.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attributeGroup ref="ActionGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @action attribute to describe the action being taken.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="NotesType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Notes are a collection of notes in a list.
|
|
|
|
If the @type attribute is set to "footnotes", then the footnotes
|
|
are intended to be shown at the bottom of the page in which they
|
|
are referenced.
|
|
|
|
If the @type attribute is set to "endnotes", then the endnotes
|
|
are intended to be shown at the end of the document.
|
|
|
|
If the @type attribute is not used or is set to "inline", then
|
|
the notes should be shown inline.
|
|
|
|
If the @type attribute is set to "uscNotes", then the notes
|
|
are intended to be shown associated with section or level of the
|
|
U.S. Code.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:choice>
|
|
<xsd:sequence>
|
|
<xsd:element ref="heading" minOccurs="0"/>
|
|
<xsd:element ref="subheading" minOccurs="0"
|
|
maxOccurs="unbounded"/>
|
|
<xsd:element ref="note" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <notes> element is a collection of note elements.
|
|
Typically, rather than using the abstract <note>
|
|
element, the notes will be either <statutoryNote>
|
|
elements or <editorialNote> elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
<xsd:element ref="layout"/>
|
|
</xsd:choice>
|
|
<xsd:attributeGroup ref="NoteGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @type attribute is used to position the notes and the
|
|
@topic attribute to categorize the notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="NoteType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A note is an annotation recording important information about the
|
|
legislation. There are three basic types of notes:
|
|
|
|
- Statutory notes are considered part of the law.
|
|
- Editorial notes are added to the legislation to convey information that is not statutory in nature.
|
|
- Source notes are a type of editorial note that records historical
|
|
references to documents which affected the legislation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="ContentType">
|
|
<xsd:attributeGroup ref="NoteGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @type attribute is used to position the note and the
|
|
@topic attribute to categorize the note.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attributeGroup ref="DateGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @date attribute is used to associate dates with a note.
|
|
This can be used to generate alerts.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="AppendixType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The appendix type is used to attach associated documents to the main
|
|
document. Typically, appendices are schedules or explanations.
|
|
|
|
Appendices can be either included within (as is usually the case)
|
|
or they can be referenced via a URL.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:group ref="NumStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <appendix> may or may not be numbered.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="HeadingStructure" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <appendix> may or may not have a heading.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:group ref="TocStructure" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <appendix> may or may not have a table of contents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:group>
|
|
<xsd:choice minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
This content model is broader than necessary. It should
|
|
consist of a single block or content or a series of
|
|
items. The level structure is more open than that.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:element ref="block"/>
|
|
<xsd:group ref="LevelStructure"/>
|
|
</xsd:choice>
|
|
</xsd:sequence>
|
|
<xsd:attributeGroup ref="LinkGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
If an <appendix> is to be included by reference, use the
|
|
@src attribute with a normal URL to point to the document
|
|
to be included.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
<xsd:attribute name="orientation" type="OrientationEnum" use="optional"
|
|
default="portrait">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @orientation attribute to specify a "landscape"
|
|
orientation for the entire schedule. The orientation of
|
|
individual elements within the schedule can also be
|
|
defined.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="SignaturesType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Defines a block for a collection of signatures. An opening paragraph
|
|
is permitted as well as an ending date. In some cases, the date may
|
|
appear within the opening paragraph.
|
|
|
|
The signatures may either be specified serially in a grid-like
|
|
layout.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="BlockType">
|
|
<xsd:sequence>
|
|
<xsd:element ref="p" minOccurs="0"/>
|
|
<xsd:choice>
|
|
<xsd:element ref="signature" maxOccurs="unbounded"/>
|
|
<xsd:element ref="layout"/>
|
|
</xsd:choice>
|
|
<xsd:element ref="date" minOccurs="0"/>
|
|
</xsd:sequence>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="SignatureType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Defines a basic signature element comprising a name and optionally
|
|
the person's role, their affiliation, and a date. All fields can be
|
|
defined to include either an @href or an @idref to point to an
|
|
identifying resource that describes the person, their role, and
|
|
their affiliation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="BlockType">
|
|
<xsd:sequence>
|
|
<xsd:element name="name" type="PropertyType" minOccurs="0"/>
|
|
<xsd:element name="role" type="PropertyType" minOccurs="0" maxOccurs="unbounded"/>
|
|
<xsd:element name="affiliation" type="PropertyType" minOccurs="0"/>
|
|
<xsd:element ref="date" minOccurs="0">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A date can be associated with a group of signatures,
|
|
or using this element with a single signature.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="RefType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The ref type is used to denote references within the text of a
|
|
document. The text of the element is the human-friendly
|
|
representation while the text in the @href of @idref attribute
|
|
is the computer-friendly representation built in accordance with
|
|
the referencing model described above.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="PropertyType">
|
|
<xsd:attributeGroup ref="AmendingGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @pos and other attributes to describe
|
|
what or where is being affected.
|
|
|
|
The attributes in the amending group should only be used
|
|
for references or actions within an amending instruction.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="DateType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The date type is used to denote dates within the text of a
|
|
document. The text of the element is the human-friendly
|
|
representation while the text in the @date attribute is the
|
|
computer-friendly normalized representation.
|
|
|
|
Dates can be specified as either dates or as date times when the
|
|
document might not coincide with the local time zone.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="PropertyType">
|
|
<xsd:attributeGroup ref="DateGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @date attribute to record a normalized value of the
|
|
date according to ISO 8601.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="QuotedTextType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A quoted text type is an extraction of simple text from another
|
|
source or origin. If the quoted text is to have literal quotes
|
|
surrounding it, then those characters must be included in the text
|
|
surrounding the quoted text and not within it.
|
|
|
|
Quoted text is seen in amendments or modifications.
|
|
|
|
Use the @identifier attribute to establish the referencing context
|
|
of the quoted text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="InlineType">
|
|
<xsd:attribute name="origin" type="xsd:anyURI" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @origin attribute is used to refer to the origin of
|
|
quoted text. The value must always be specified as a
|
|
relative URL conforming to the reference specification.
|
|
|
|
The @origin attribute is optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="QuotedContentType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A quotedContentType is used for an extraction of potentially structured
|
|
text (text with XML elements) from another source or origin.
|
|
|
|
Quoted content is seen in USC Notes, amendments, and modifications.
|
|
|
|
Use the @identifier attribute to establish the referencing context
|
|
of the quoted structure
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="ContentType">
|
|
<xsd:attribute name="origin" type="xsd:anyURI" use="optional">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @origin attribute is used to refer to the origin of
|
|
quoted text. The value must always be specified as a
|
|
relative URL conforming to the reference specification.
|
|
|
|
The @origin attribute is optional.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Structural Building Blocks -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="NoteStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Notes can be defined in a variety of ways and tend to occur in many
|
|
different places throughout legislation.
|
|
|
|
This structure allows for either individual notes or groups of
|
|
notes.
|
|
|
|
The number of times the notes might appear should be specified with
|
|
each use of this group.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:choice>
|
|
<xsd:element ref="note"/>
|
|
<xsd:element ref="notes"/>
|
|
</xsd:choice>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="NumStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The num structure allows for an unlimited number of occurrences in
|
|
a simple sequence. This is to allow an item to be renumbered without
|
|
creating a whole new parent item, typically a level or appendix structure.
|
|
Each <num> element should apply to a different temporal period.
|
|
|
|
Notes will typically only follow a <num> when found in a repealed,
|
|
omitted, spent, or otherwise removed section or level that is being
|
|
noted.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:element ref="num" maxOccurs="unbounded"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="HeadingStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The primary structure of headings.
|
|
|
|
A <heading> should exist only once for a single temporal period.
|
|
Multiple headings are permitted to support versioning without having
|
|
to create a whole new parent level or appendix. This is
|
|
important in hierarchical upper levels where it is not desirable to
|
|
generate a whole new level should part of the heading change.
|
|
|
|
Use the optional <subheadings> in cases where there is one or more
|
|
subheadings to the parent item. Like the <heading> element,
|
|
different <subheading> elements can be added to apply to different
|
|
temporal periods.
|
|
|
|
Notes may follow the heading. Often this is a source note.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:element ref="heading" maxOccurs="unbounded"/>
|
|
<xsd:element ref="subheading" minOccurs="0" maxOccurs="unbounded"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="TocStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The table of contents structure defines the simple case of a <toc>
|
|
followed by optional notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:element ref="toc"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="StatementStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The statement structure defines the simple case of a <statement>
|
|
(such as a <docTitle> or <longTitle>) followed by optional notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:element ref="statement"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="RecitalStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The recital structure defines the simple case, found in a preamble,
|
|
of a recital followed by optional notes. Recitals usually start with
|
|
"Whereas,".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:element ref="recital"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="PreambleStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The preamble structure defines the case where either a <preamble> or
|
|
an <enactingFormula> can exist within the <main> part of a <lawDoc>.
|
|
When a <preamble> is used, the <enactingFormula> is found within
|
|
the <preamble>, at the bottom.
|
|
|
|
Notes may be defined after the <preamble> or <enactingFormula>.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:sequence>
|
|
<xsd:choice >
|
|
<xsd:element ref="preamble"/>
|
|
<xsd:element ref="enactingFormula"/>
|
|
</xsd:choice>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:group name="LevelStructure">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The level structure is the primary structure of hierarchy. A level
|
|
is structured either as an instruction, loosely structured content,
|
|
or as hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:choice>
|
|
<xsd:sequence maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Multiple <instruction> elements should only be used for cases
|
|
where the instruction has been versioned and it is not desirable
|
|
to create a whole new version of the parent level. This use
|
|
case should be very rare.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:element ref="instruction" maxOccurs="unbounded"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
<xsd:sequence>
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Multiple <content> elements should only be used for cases
|
|
where the content has been versioned and it is not desirable
|
|
to create a whole new version of the parent level. This use
|
|
case should be very rare.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:element ref="content" maxOccurs="unbounded"/>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
<xsd:sequence maxOccurs="unbounded">
|
|
<xsd:choice>
|
|
<xsd:element ref="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Used for content interspersed between levels in a hierarchical
|
|
structure, such as an opening <chapeau>, an
|
|
interstitial or closing <continuation>, or a <proviso>.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
When a <level> is not the lowest level of a hierarchy, it
|
|
will primarily be made up of child levels.
|
|
|
|
It is generally desirable to push all versioning down to
|
|
lower elements to avoid replicating large portions of
|
|
the document to support version changes. This means that
|
|
the <num>, <heading>, and <subheading> elements should
|
|
be defined across different temporal periods rather than
|
|
defining <level> elements across temporal periods.
|
|
However, <level> elements can be defined with the
|
|
temporal attributes and this applies to the lower levels,
|
|
such as the <section> level, where practical
|
|
considerations necessitate versioning at the <level>
|
|
element.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element ref="crossHeading">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A cross heading is an interstitial heading appearing
|
|
between level items, but is not part of the hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:choice>
|
|
<xsd:group ref="NoteStructure" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:choice>
|
|
</xsd:group>
|
|
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Core Declarations -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:element name="lawDoc" type="LawDocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <lawDoc> is a base level element representing all types of
|
|
legislative documents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="document" type="GenericDocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <document> is a base level element for loosely structured
|
|
documents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="meta" type="MetaType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <meta> block contains properties and sets of properties recording
|
|
metadata about the document. The information contained within the
|
|
meta block is not part of the official law and should not be printed
|
|
as such. Ordinarily, all text content in a document is intended for
|
|
publication in textual representations of the document. However,
|
|
this is not the case for textual content in the <meta> block. If,
|
|
for instance, a property in the meta block has text content, it
|
|
does not automatically become text to be included in a published
|
|
form. However, in some case this may be desirable and can be done.
|
|
However, the meaning is not implicit.
|
|
|
|
The <meta> block may contain elements from the Dublin Core.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="property" type="PropertyType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <property> is simple value recorded with the document. Typically
|
|
properties are stored in the <meta> block of the document. However,
|
|
this is not necessarily the case. It is possible to also define
|
|
properties within any content area in the document. A case where
|
|
this occurs is the definition of the short title. The short title
|
|
is treated as a property (the <docTitle> element is a derivation
|
|
from the <property> element).
|
|
|
|
If a property in the <meta> block has textual content, then this
|
|
text is not implicitly intended for publication. However, if a
|
|
property outside the <meta> block has textual content, then this
|
|
text is implicitly intended for publication.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="set" type="SetType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <set> is a grouping of properties in the <meta> block. Sets
|
|
themselves can contain other sets. Sets can be typed using the
|
|
@type attribute with the SetTypeEnum enumeration. By default, sets
|
|
are simply unordered bags of properties.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="toc" type="TocType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <toc> is a table of contents. A table of contents can appear in a
|
|
number of locations in document. A table of contents can appear in
|
|
three different locations:
|
|
|
|
- It can appear anywhere within the top of the <main> element,
|
|
before the levels.
|
|
- It can appear in any level following the <heading>, <subheading>,
|
|
and any notes.
|
|
- It can appear in an <appendix>.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="tocItem" type="TocItemType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <tocItem> is an entry in a table of contents. In addition to being
|
|
found within a <toc> element, a <tocItem> can contain other <tocItem>
|
|
elements in a hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="main" type="MainType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <main> is the primary container for the body of a legislative
|
|
document.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="statement" type="StatementType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <statement> is the general container for the provisions at the
|
|
beginning of legislation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="preamble" type="PreambleType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <preamble> is a container for the "Whereas" clauses and the
|
|
enacting formula. Modern practice is to not use the preamble,
|
|
but to use a standalone enacting formula. However, for the rare
|
|
cases where a preamble is desired, the tags are made available.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="recital" type="StatementType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <recital> is a preliminary statement in a bill stating the reasons
|
|
for the Bill. Modern legislation seldom uses a recital although it
|
|
can still occur.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="enactingFormula" type="StatementType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <enactingFormula> is specified just before the main provisions of
|
|
a bill. The <enactingFormula> can appear as either the last statement
|
|
in a preamble or, when a preamble is not present, standalone within
|
|
the main element just prior to the main provisions.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="level" type="LevelType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <level> is the general container for the main provisions of
|
|
legislation, often organized as a hierarchy.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="num" type="NumType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <num> surrounds the numeric designation assigned to a level
|
|
in legislation. Numbering is not always present. The number should
|
|
always include the surrounding decoration including descriptive
|
|
text and parenthesis and grammar. This number should never be
|
|
auto-generated. A normalized value based on the text content of the
|
|
<num> element should be stored in the @value attribute.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="text" type="ContentType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <text> element is a base class for <chapeau>, <continuation>,
|
|
<proviso>, <def> and any other type of text that can be interspersed
|
|
in the hierarchy of a document. It is similar to the <content> tag,
|
|
but has more limited applicability. In general, use the <content>
|
|
tag when a hierarchical level is made up largely of general content
|
|
and use the one of its derivatives of the text tag when limited text
|
|
is found interstitially between levels or other tags.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="heading" type="HeadingType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <heading> is an optional part of a level element and various other
|
|
elements. The heading is based on the content primitive and can contain
|
|
various elements including definitions.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subheading" type="HeadingType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <subheading> is an optional part of a level element and various
|
|
other elements. Like the heading, the subheading is based on the
|
|
content primitive and can contain various elements including
|
|
definitions. A subheading should only be created if a heading
|
|
already exists.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="crossHeading" type="HeadingType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <crossHeading> is a non-hierarchical heading construct which can
|
|
be placed within and amongst heading levels. A <crossHeading> acts
|
|
as a divider, separating items within a level.
|
|
|
|
Cross headings are typically shown as center-aligned headings
|
|
without any level identification or level numbering.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="instruction" type="InstructionType" abstract="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <instruction> is a container having formalized text describing an
|
|
amendment or a modification. An <instruction> contains the <action>s
|
|
and <quotedText>/<quotedContent> necessary to describe an
|
|
amendment.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="action" type="ActionType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <action> is an atomic-level change defined within an amending
|
|
formula. The action contains the text related to that action and,
|
|
through attributes, identifies the item affected and the type of
|
|
action to be performed.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="notes" type="NotesType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <notes> is a container for collections of individual notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="note" type="NoteType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <note> is a generic element for notes associated with items in the
|
|
document. Typically, a derived note type should be used to
|
|
differentiate between official statutory notes and unofficial
|
|
editorial notes.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="appendix" type="AppendixType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <appendix> is a generic element appended to the main part of a
|
|
document. Appendices can either be inline or included via a @src
|
|
reference. Typically the appendix tag is not used. Rather, the
|
|
derived tags such as <schedule> and <explanation> are used instead.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="signatures" type="SignaturesType" substitutionGroup="block">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Some documents, may conclude with one or
|
|
more signatures indicating sponsorship or approval. These
|
|
signatures are placed within this container.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="signature" type="SignatureType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <signature> consists of a name and, optionally, role, affiliation,
|
|
and/or date. Both the name and the role may be hyperlinked to something
|
|
which identifies the person or role.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Substitution groups allow the elements below to appear in
|
|
numerous places. -->
|
|
|
|
<xsd:element name="ref" type="RefType" substitutionGroup="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <ref> element is a reference or link to another document, a
|
|
location within another document, or a location with the same
|
|
document.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="date" type="DateType" substitutionGroup="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <date> element is a wrapper around dates. A normalized value
|
|
of the date text can be stored in the @date attribute or in the
|
|
@startDate and @endDate attributes in the case of a date range.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="quotedText" type="QuotedTextType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <quotedText> element is used for an extraction of simple text from
|
|
another source or origin. If the quoted text is to have literal
|
|
quotes surrounding it, then those characters must be included in the
|
|
text surrounding the quoted text and not within it.
|
|
|
|
Quoted text is seen in amendments or modifications.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="quotedContent" type="QuotedContentType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <quotedContent> element is used for an extraction of potentially structured
|
|
text (text with XML elements) from another source or origin.
|
|
|
|
Quoted content is used in USC Notes, amendments, and modifications.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Generic Definitions -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:complexType name="LayoutType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A layout type is used to denote an area of text intended to
|
|
be displayed in a column-oriented layout similar to a table. Use
|
|
the <header>, <row>, and <column> elements to denote the rows and
|
|
columns of the structure. A <layout> can be either row oriented or
|
|
column oriented.
|
|
|
|
Use layout types when describing legislative structure in a column
|
|
oriented fashion. For regular tables as shown in forms, use HTML
|
|
tables.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:choice minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <layout> type can contain various types of elements
|
|
as rows including headers, rows, TOC items, blocks,
|
|
and contents. All elements, aside from <column> elements,
|
|
are treated as rows when found directly within a layout
|
|
structure.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:element ref="header"/>
|
|
<xsd:element ref="row"/>
|
|
<xsd:element ref="tocItem"/>
|
|
<xsd:element ref="block"/>
|
|
<xsd:element ref="content"/>
|
|
<xsd:group ref="NoteStructure"/>
|
|
</xsd:choice>
|
|
<xsd:attribute name="orientation" type="OrientationEnum" use="optional" default="portrait">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @orientation attribute is used to specify a landscape
|
|
orientation for the published form. This is primarily used
|
|
for schedules or tables.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="RowType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A row type denotes a row entry within a layout structure. In
|
|
addition to the formal <row> element, any child element directly in
|
|
a <layout> element, aside from a <column> element, is regarded as a
|
|
row.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="BaseBlockType">
|
|
<xsd:sequence>
|
|
<xsd:element ref="column" minOccurs="1" maxOccurs="unbounded">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A row contains one or more column cells.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="ColumnType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A column type is a cell in a layout structure. As a <content>
|
|
element, it can contain a wide range of text and elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent mixed="true">
|
|
<xsd:extension base="ContentType">
|
|
<xsd:attributeGroup ref="CellGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the elements of the cell group to specify
|
|
the row and column spans.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="PType" mixed="true">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A "P" type is a simple unnumbered paragraph. As a <content>
|
|
element, it can contain a wide range of text and elements.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="ContentType"/>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="BrType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A break type is simple marker element denoting a line break.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:simpleContent>
|
|
<xsd:extension base="MarkerType"> </xsd:extension>
|
|
</xsd:simpleContent>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="ImgType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An image type is a simple marker element denoting where a graphic
|
|
image is to be inserted.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:extension base="MarkerType">
|
|
<xsd:attribute name="orientation" type="OrientationEnum" use="optional" default="portrait">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The @orientation attribute is used to specify a landscape
|
|
orientation for the published form. If the @orientation attribute
|
|
is not set, the default orientation for all elements is portrait.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attribute>
|
|
<xsd:attributeGroup ref="LinkGroup">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use the @src attribute to point to the image with a normal URL.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:attributeGroup>
|
|
</xsd:extension>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Generic Declarations -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:element name="layout" type="LayoutType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <layout> element is used to denote an area of text intended to
|
|
be displayed in a columns-oriented format similar to table. Use
|
|
the <header>, <row>, and <column> elements to denote the rows and
|
|
columns of the structure.
|
|
|
|
Use <layout> when describing legislative structure in a column-
|
|
oriented fashion. For regular tables as shown for forms, use HTML
|
|
tables.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="header" type="RowType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <header> denotes a header row within a column-based structure.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="row" type="RowType">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <row> denotes a row entry within a column-based structure.
|
|
In addition to the formal <row> element, any child element
|
|
in a <layout> element, aside from a <column> element, is regarded as
|
|
a row. There should always be a <layout> element as an
|
|
ancestor of a <row>. Both column and row spans may be defined for
|
|
<row> entries.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="column" type="ColumnType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <column> denotes a column when specified directly under a <layout>
|
|
or a cell when specified within a <row> (or equivalent) in a
|
|
<layout> structure. There should always be a <layout> element as an
|
|
ancestor of a <column>. Both column and row spans may be defined for
|
|
<column> entries.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="p" type="PType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <p> is a simple paragraph. This is different from the
|
|
more complex numbered <paragraph> element used for
|
|
the formal paragraph level of legislative documents.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="br" type="BrType" substitutionGroup="marker">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <br> is simple marker element denoting a line break.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="img" type="ImgType" substitutionGroup="marker">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <img> is a simple marker element denoting where a graphic
|
|
image is to be inserted. Use the @src attribute to point to the
|
|
image with a normal URL.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="center" type="ContentType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <center> is content text to be centered on the page.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="fillIn" type="ContentType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <fillIn> is an inline spacer which denotes an area to be filled
|
|
in a printed form. Usually, a <fillIn> is rendered as dotted lines
|
|
with the text content within the <fillIn> tags shown just below. If
|
|
parenthesis are to surround the text shown below the line, then
|
|
those parenthesis should be included in the text content.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="checkBox" type="ContentType" substitutionGroup="content">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <checkBox> is an inline tick box which denotes a box to be filled
|
|
in on an form.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="b" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <b> is a simple inline text to be shown in bold text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="i" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <i> is a simple inline text to be shown in italic text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="sub" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <sub> is a simple inline text to be shown in subscript text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="sup" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <sup> is a simple inline text to be shown in superscript text.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="del" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <del> is a simple inline text to be shown in deleted text
|
|
within a modification.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="ins" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <ins> is a simple inline tag to be used to show inserted text
|
|
within a modification.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- ==================================================================== -->
|
|
<!-- Synonyms -->
|
|
<!-- ==================================================================== -->
|
|
|
|
<xsd:element name="bill" type="LawDocType" substitutionGroup="lawDoc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <bill> is a document containing proposed law. When enacted, a
|
|
<bill> becomes an <statute>.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="statute" type="LawDocType" substitutionGroup="lawDoc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <statute> is a document containing an enacted bill.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="resolution" type="LawDocType" substitutionGroup="lawDoc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <resolution> is a simple resolution, joint resolution, or concurrent
|
|
resolution, as those terms are defined by the U.S. Congress.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<xsd:element name="amendment" type="LawDocType" substitutionGroup="lawDoc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <amendment> is a document containing a pre-enactment stage amendment.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<xsd:element name="uscDoc" type="LawDocType" substitutionGroup="lawDoc">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <uscDoc> is a document containing a title or appendix of the
|
|
U.S. Code.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- PropertyType -->
|
|
|
|
<xsd:element name="docNumber" type="PropertyType" substitutionGroup="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <docNumber> is a property that contains a numeric designation
|
|
assigned to this document. The document number should not contain
|
|
any document prefix. Use the <docType> for the prefix.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="docPublicationName" type="PropertyType" substitutionGroup="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <docPublicationName> is a property used to record the name of
|
|
the publication that this document is part of. The values of the
|
|
<docPublicationName> are not defined.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="docReleasePoint" type="PropertyType" substitutionGroup="property">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <docReleasePoint> is a property used to record the point the document
|
|
was released. The values of the doc status are not defined. For a USC title,
|
|
this may be the Public Law number that the title is updated through.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- StatementType -->
|
|
|
|
<xsd:element name="docTitle" type="StatementType" substitutionGroup="statement">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <docTitle> is a statement that precedes the long title in legislation. The short title is declared in the
|
|
first clause of a bill and is tagged in that location using the
|
|
<shortTitle> tag.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="longTitle" type="StatementType" substitutionGroup="statement">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <longTitle> is a statement that sets out the purposes of the bill
|
|
in general terms.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- InlineType -->
|
|
|
|
<xsd:element name="shortTitle" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The <shortTitle> element is used to surround the short title when it
|
|
is first defined, usually in the first clause of the bill. Note
|
|
that the <shortTitle> element is to be used in this case rather than
|
|
the <docTitle> element.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="term" type="InlineType" substitutionGroup="inline">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <term> is always defined within a definition. The <term> element
|
|
surrounds the words for the term being defined. It is quite possible
|
|
for multiple <term> elements to be specified within a definition.
|
|
When a <term> is the words, in the alternate language, then the
|
|
xml:lang attribute must be used. <term> elements can also be used
|
|
for synonyms or near-synonyms which are also specified within the
|
|
definition.
|
|
|
|
There are two ways in which defined terms are presented. The modern
|
|
form is to present the term in bold and/or italic. The older form
|
|
is to present the terms bounded by open and close double quotes. In
|
|
all cases, the term (excluding the quotation marks) should be bound
|
|
with the <term> element. The presentation should be determined based
|
|
on the use of the @class and the @style attributes (TBD). It is
|
|
important that the semantics be captured in the tags and that the
|
|
presentation be separated and isolated to the styling attributes.
|
|
|
|
Notes:
|
|
|
|
(1) In some cases, a term from the opposite language may be defined
|
|
without a term in the primary language and the term will be used as
|
|
such in the legislation despite being in the opposite language.
|
|
|
|
(2) It is possible that a <term> appear multiple times within a
|
|
definition and be identified as a <term> (along with the
|
|
corresponding interpretation) each time the term appears.
|
|
|
|
(3) In some rare cases, a term may be defined to include the open
|
|
and close quotes. In newer presentation forms, the term with the
|
|
quotation marks will be found within the bold and/or italics while
|
|
in older presentation forms, the term will show as a pair of open
|
|
and a pair of close quotation marks. In that case, the inner
|
|
quotation marks should be treated as part of the term itself.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- LevelType -->
|
|
|
|
<xsd:element name="preliminary" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <preliminary> level is used to create a hierarchical region
|
|
of the main document consisting of preliminary clauses that
|
|
are outside of the main document hierarchy.
|
|
|
|
When naming a preliminary level, the case-sensitive prefix "prelim".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Levels above the Section -->
|
|
|
|
<xsd:element name="title" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <title> is the top hierarchical level of a legislative document.
|
|
|
|
When naming a title, use the case-sensitive prefix "t".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subtitle" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subtitle> is a hierarchical level of a legislative document.
|
|
|
|
When naming a subtitle, use the case-sensitive prefix "st".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="part" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <part> is a hierarchical level of a legislative document.
|
|
|
|
When naming a part, use the case-sensitive prefix "p".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subpart" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subpart> is a hierarchical level of a legislative document.
|
|
|
|
When naming a subpart, use the case-sensitive prefix "sp".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="division" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <division> is a hierarchical level of a legislative document.
|
|
|
|
When naming a Division, use the case-sensitive prefix "d".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subdivision" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subdivision> is a hierarchical level of a legislative document.
|
|
|
|
When naming a subdivision, use the case-sensitive prefix "sd".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="chapter" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <chapter> is a hierarchical of a legislative document.
|
|
|
|
When naming a chapter, use the case-sensitive prefix "c". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subchapter" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subchapter> is a hierarchical level of a legislative document.
|
|
|
|
When naming a subchapter, use the case-sensitive prefix "sc". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="article" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <article> is a used in bills.
|
|
|
|
When naming an article, use the case-sensitive prefix "a". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subarticle" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subarticle> is used in bills.
|
|
|
|
When naming a subarticle, use the case-sensitive prefix "sa". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Appendices -->
|
|
|
|
<xsd:element name="compiledAct" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <includedAct> is used in title appendices.
|
|
|
|
When naming a compiledAct, use the case-sensitive prefix "cact". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="courtRules" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
<courtRules> is used in title appendices.
|
|
|
|
courtRules is a containment level that is not named. ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="courtRule" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <courtRule> is used in appendices.
|
|
|
|
When naming a courtRule, use the case-sensitive prefix "crule". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="reorganizationPlans" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
<reorganizationPlans> are used in title appendices.
|
|
|
|
reorganizationPlans is a containment level that is not named. ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="reorganizationPlan" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <reorganizationPlan> is used in title appendices.
|
|
|
|
When naming a reorganizationPlan, use the case-sensitive prefix "rplan". ]]>
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Section Level -->
|
|
|
|
<xsd:element name="section" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <section> is the primary hierarchical level in a USC Title or a bill.
|
|
|
|
When naming a section, use the case-sensitive prefix "s".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Levels below the Section -->
|
|
|
|
<xsd:element name="subsection" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subsection> is an optional hierarchical level below a section.
|
|
Subsections are usually numbered with lower-case letters.
|
|
|
|
When naming a subsection, use the case-sensitive prefix "ss".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="paragraph" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <paragraph> is a numbered level usually found below a
|
|
subsection in the document hierarchy. Paragraphs are
|
|
usually numbered with Arabic numbers.
|
|
|
|
When naming a paragraph, use the case-sensitive prefix "p".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subparagraph" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subparagraph> is a level below a paragraph in the document
|
|
hierarchy. Subparagraphs are usually numbered with upper-case
|
|
letters.
|
|
|
|
When naming a subparagraph, use the case-sensitive prefix "sp".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="clause" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <clause> is an optional below-section hierarchical level.
|
|
Clauses are usually numbered with lower-case Roman numerals.
|
|
|
|
When naming a subclause, use the case-sensitive prefix "sc".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subclause" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subclause> is an optional hierarchical level below a clause.
|
|
Subclauses are usually numbered with upper-case Roman numerals.
|
|
|
|
When naming a subclause, use the case-sensitive prefix "sc".
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="item" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <item> is a level usually below a subclause in the document
|
|
hierarchy. Items are usually numbered with double lower-case
|
|
letters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subitem" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subitem> is a level below an item in the document
|
|
hierarchy. Subitems are usually numbered with double upper-case
|
|
letters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="subsubitem" type="LevelType" substitutionGroup="level">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <subsubitem> is a level below a subitem in the document
|
|
hierarchy. Subsubitems are usually numbered with triple lower-case
|
|
letters.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- TextType -->
|
|
|
|
<xsd:element name="def" type="ContentType" substitutionGroup="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <def> defines a term. It contains one or more <term> elements
|
|
identifying the term being defined as well as the text describing
|
|
the term. It is customary for the <term> to be identified in both
|
|
languages. In the case where the term is for the opposite language,
|
|
then the xml:lang attribute should be set for the term expressed in
|
|
the opposite language. In some cases, closely related other terms
|
|
might also be identified within the text of the definition and will
|
|
also be identified with the <term> element..
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="chapeau" type="ContentType" substitutionGroup="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use a <chapeau> whenever there is introductory text that comes
|
|
before lower levels in a level hierarchy and the text alone is not
|
|
permitted by the content model.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="continuation" type="ContentType" substitutionGroup="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
Use a <continuation> for interstitial text or whenever there is
|
|
final text that comes after lower levels in a level hierarchy and
|
|
the text alone is not permitted by the content model.
|
|
|
|
Be careful not to confuse continuation text with a proviso, which has
|
|
a separate tag.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="proviso" type="ContentType" substitutionGroup="text">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <proviso> is a paragraph that states conditions relating to the
|
|
law it is related to. A proviso generally begins with "Provided that"
|
|
or just "Provided". Proviso can contain their own
|
|
complex structure including sandwich structures. When referencing
|
|
into numbered parts of a proviso, a "proviso" level is added to
|
|
the reference. If there are multiple provisos within a single
|
|
parent, then those provisos should be named.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Formula Type -->
|
|
|
|
<xsd:element name="amendingFormula" type="InstructionType" substitutionGroup="instruction">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <amendingFormula> element is an instruction used when defining an amendment
|
|
to legislation or proposed legislation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- Note Type -->
|
|
|
|
<xsd:element name="sourceCredit" type="NoteType" substitutionGroup="note">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <sourceCredit> is a note included to indicate the source of a
|
|
provision. It usually will contain a reference to the source of the
|
|
provision and the Statute(s) that have affected it. Source credits are
|
|
usually set out in parenthesis. The surrounding
|
|
parenthesis are shown in the text - they must
|
|
not be automatically added.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="statutoryNote" type="NoteType" substitutionGroup="note">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <statutoryNote> is a note that becomes part of the law.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="editorialNote" type="NoteType" substitutionGroup="note">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
An <editorialNote> is a note included for editorial purposes only. While
|
|
present in the text of the document as printed, it is not a part of
|
|
the law. Editorial notes are often used to record where provisions
|
|
have been omitted or other changes have been made.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="changeNote" type="NoteType" substitutionGroup="note">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <changeNote> is a note that records a non-substantive change that
|
|
has been made to the document. Usually
|
|
change notes are set out in square brackets and these must be set out in
|
|
the text and must not be automatically added.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- SignatureType -->
|
|
|
|
<xsd:element name="made" type="SignaturesType" substitutionGroup="signatures">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The signatures of the people making the legislation.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
<xsd:element name="approved" type="SignaturesType" substitutionGroup="signatures">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
The signature of the people approving the document.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- AppendixType -->
|
|
|
|
<xsd:element name="schedule" type="AppendixType" substitutionGroup="appendix">
|
|
<xsd:annotation>
|
|
<xsd:documentation><![CDATA[
|
|
A <schedule> is an appendix to a bill or other document.
|
|
It contains a wide variety of content and the containment model is
|
|
consequently quite loose. A <schedule> is often a list of numbered items,
|
|
sometimes arranged in columns. Sometimes a schedule is a list of
|
|
consequential amendments. Schedules can also be tables or documents
|
|
defined externally such as extradition treaties or trade agreements.
|
|
Schedules are sometimes printed in a landscape rather that portrait
|
|
orientation.
|
|
|
|
In order to support the wide variety of content types, it is possible
|
|
to embed arbitrary HTML content in a <content> element within a
|
|
schedule.
|
|
]]></xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element>
|
|
|
|
<!-- ==================================================================== -->
|
|
|
|
</xsd:schema>
|