[[enactment_clause]]
Be it enacted by the <legislative body> of the <type> of <jurisdiction_name> as follows:Views and ideas expressed on this site are those of the contributors only. They do not reflect any views or positions held by New York State. See our GitHub group for a list of contributors.
The purpose of this document is to describe how local laws will be expressed in Asciidoctor. It assumes that the body of law for each jurisdiction will reside in a discrete repository.
An expression of a specific local law at a point in time. Local governments are required to express and submit their laws in this form to DOS. This is generally what government officials call a "local law".
The New York State Department of State. Local governments are required to file laws with this agency before they may take effect.
Any formal compilation of multiple local laws. Local governments are not required to codify their laws, but many do to simplify research and make the body of law easier to understand. Municipal Home Rule Law § 27(6) requires the local official who is responsible for filing local laws to maintain “a separate book or books, which shall be indexed”. Such a book or collection of books is effectively one codified expression.
The root directory of the repository containing the body of law for a jurisdiction.
A repository node expresses a structural part of the law within the repository.
A node that resides in the repository root.
This section describes how repository nodes are structured in various platforms in development.
|
Note
|
The GitLaw platform used to have separate JSON and adoc files respectively for node metadata and text. It now combines them in one file as described here. |
A node is represented by a name.adoc file, where name is the name of the node.
Metadata are contained in the front-matter of the file.
Metadata are formatted in Yet Another Markup Language (YAML).
If the section has text, it is contained in the body of the file after the front-matter.
If the section contains sub-units, they can either be included in the body or in a folder name containing nodes representing each subunit.
Metadata are organized in a Hash structure.
| Key | Format | Purpose | Optional |
|---|---|---|---|
structure |
array of hashes |
Hierarchy of node types allowed under this node. See Attributes of Structure Definitions. |
no |
type |
string |
The type of the node, which should correspond to a |
yes |
title |
string |
The title for the node. |
no |
number |
integer |
The numerical identifier for the node. This is always stored as an integer, even if it will be rendered in a different format. |
no |
The structure attribute, if provided contains hashes representing in each level of the hierarchy, starting with the immediate children of the node.
| Key | Format | Purpose | Optional |
|---|---|---|---|
label |
string |
Label for the type of node at this level. |
yes |
number |
character |
Specifies how numbers for sections at this level should be realized
|
yes |
optional |
boolean |
True if nodes of this type must always be included in the hierarchy. False if they are sometimes omitted. |
yes |
text |
boolean |
True if node can have textual content. |
yes |
title |
boolean |
True if node can have a textual title. |
yes |
Root nodes have a type of code and are not numbered.
These should represent the book or books into which the municipality organizes its laws.
This section describes how chronological expressions should be rendered in a repository.
Chronological expressions are organized in a convention that effectively forms a codification by default.
These expressions will reside under a root node laws.
The laws node contains a child node for each year in which a law was adopted.
For example, the 2014 node would contain all laws adopted in 2014 for the jurisdiction.
Each year node contains a node for each law adopted in that year.
The name of the node would be the number of the law adopted in the year.
For example, Local Law No. 5 of 2014 would be in a node named law-05 within the 2014 node.
Local governments have few constraints in how the structure the content of the law. Each law could be broken down into a structure of multiple nodes or it could be contained in a single node. In general, laws are short and simple enough that they can be contained in a single node. This will be the preferred practice.
The law must start with an enactment clause.
[[enactment_clause]]
Be it enacted by the <legislative body> of the <type> of <jurisdiction_name> as follows:The law must end with a certification statement.
[[certification]]
<text determined by municipality>The content in between these statements is considered the text of the law.
Text that resides in a codified expression should not be included directly in the law.
Instead it should reside in the codified expression.
A child asset of the node called diff.adoc should describe how the text of the codification is altered.
This file will consist of a series of statements, such as this:
[[amendment_instruction]]
Chapter 5, Section 1 of the Administrative Code created by Local Law 5 of 2002
and amended by Local Law 2 of 2008 is amended to read as follows:
include::administrative-code/chapter-5/section-1.adoc[]
...This can be generated automatically using a diff tool that compares the adopted law version to the current version to which it will be applied. The diff should use include statements to include the text from the codified expression where it resides. The diff itself can be included in the text of the law by reference.
Before a proposed law is adopted, it cannot be assigned to the laws node.
Instead, it should reside in a special root node named proposed.
On adoption this node will be moved to the appropriate place in the laws node hierarchy.
Elements of the law may be organized into one or more codified expressions.
Each book should be contained in a hierarchy under a root node.
For example the "Administrative Code" of a municipality might be in a root node named administrative-code.