uslm-components-2.1.0.xsd

====================================================================== * United States Legislative Model (USLM)* ====================================================================== ** Objective ** This schema provides a general schema for modeling United States legislative and regulatory documents, including: * United States Code titles and appendices. * Enrolled Bills * Public and Private Laws * Statutes at Large * Statute Compilations * Federal Register * Code of Federal Regulations It is designed to be extendable to future legislative and regulatory documents. The intent is to support XML data delivery, publishing, editing, and automated processing of the documents. 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 this content is included in the documents that are within scope. ** 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 other 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. ** 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. Each of these attributes may or may not be used in all situations: * 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 uniqueness in all space and time. The @id should be given a simple "id" prefix. * The @identifier attribute specifies the URL context and identity of the element. Typically, the @identifier will be established on the root element or on any element, such as a <quotedContent> or <quotedText> element, that changes the context. * 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 to which 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 use an abbreviated prefix or a numeric/ alphabetic entry to identify the target. Each level in the reference is 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 with "/" + the level designators. So a reference to "title 2 of division 3 of public law 113-314" would be "/us/pl/111/314/d3/t2". 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, using the three-letter language identifier defined in ISO 639-2, as used by the Library of Congress, using the Bibliographic language code (B) where there is a choice. (https://www.loc.gov/standards/iso639-2/php/code_list.php) For instance, to specify a reference to section 101 of the English version of title 51, the reference would be "/us/usc/t51!eng/s101". To make a reference to a specified version of a provision or level, an "@" symbol is used. For instance, to specify a reference to section 101 of Title 51 on 1 February, 2013, the reference would be "/us/usc/t51@2013-02-01/s101", which uses the ISO time reference system. The version specification could also be an arbitrary name or relative date, such as 'pre-1824' or 'v1.1.1'. A version string that is not a date must not begin with a number, to avoid confusion with dates. Version strings must not contain special characters or spaces. When including both a language and a version specification, place the language specification ahead of the version specification. For instance to combine both examples above, the result would be "/us/usc/t51!eng@2013-02-01/s101" or "/us/usc/t51!eng@v1.1.1/s101".