eCH-0296 – Erlasse und Gesetzestexte

1. Einleitung

1.1. Status

1.2. Anwendungsgebiet

Das Anwendungsprofil eCH-0296 ist eine Lokalisierung des Akoma Ntoso (AKN) [AKN] und des European Legislation Identifier (ELI) [ELI] Standards für die Schweiz. AKN ist ein XML-Standard für Dokumente in den Bereichen parlamentarische Geschäfte, Gesetzgebung (Legislative) und Rechtsprechung (Judikative). ELI ist ein System für die Identifizierung von Rechtsvorschriften, welches auf einem gemeinsamen Standard beruht.

Die Bereitstellung der Gesetzessammlung in digitaler Form wird in der angestrebten Soll-Architektur des Systems E-Government Schweiz [eCH-0122] als Geschäftsfähigkeit mit Voraussetzungscharakter definiert. Durch Herstellung der semantischen und Ermöglichung der technischen Interoperabilität zwischen allen Verwaltungsebenen können der Austausch von Rechtsdaten vereinfacht und Redundanzen eliminiert werden. Die angestrebte Interoperabilität wird erreicht indem alle Verwaltungsebenen ihre Erlasse und Gesetzestexte in strukturierter und maschinenlesbarer Form veröffentlichen. Das Anwendungsprofil eCH-0296 ermöglicht dies, indem es für den Gesetzgebungs- und Publikationsprozess eine einheitliche Sprache und Schnittstellen definiert.

Im Einzelnen unterstützt eCH-0296 folgende Anwendungsfälle:

• Strukturierte Publikation von Erlassen: Einheitliche, maschinenlesbare Abbildung von Gesetzen, Verordnungen und weiteren Erlassen mittels AKN.

• Eindeutige Identifikation und Verlinkung: Vergabe persistenter, auflösbarer Identifikatoren für Erlasse und deren Bestandteile mittels ELI, ebenenübergreifend von der Gemeinde bis zum Bund.

• Föderierter Zugang zu Rechtssammlungen: Ermöglichung des standardisierten Austauschs und der Aggregation von Erlassdaten zwischen den Verwaltungsebenen und mit europäischen Systemen.

1.3. Aufbau

Der Hauptteil besteht aus drei normativen Modulen, die aufeinander aufbauen:

1. Identifier (Kapitel 2): Regeln zur Bildung von gültigen URIs für Gesetze und andere Dokumente im Gesetzgebungsprozess.

2. Content (Kapitel 3): Die unterschiedlichen Dokumententypen und deren Struktur.

3. Metadata (Kapitel 4): Daten, welche die Dokumente und Beziehungen unter den Dokumenten weiter beschreiben.

Das vorliegende Kapitel 1 ist rein informativer Natur und verfolgt zwei Ziele:

• Einerseits wird Bezug auf die übergeordneten Arbeiten der Fachgruppe Politische Geschäfte genommen, indem es die Begrifflichkeiten rund um den Gesetzgebungs- und Publikationsprozess und die Dokumententypen, die dabei entstehen, definiert.

• Andererseits werden die Grundlagen technischer und konzeptioneller Natur vermittelt, die für das Verständnis der normativen Module vorausgesetzt werden.

Darüber hinaus ist jeweils der erste Abschnitt jedes Moduls ebenfalls rein informativer Natur.

1.4. Fachgruppe Politische Geschäfte

Das Anwendungsprofil eCH-0296 ist das Ergebnis der Arbeiten der Fachgruppe Politische Geschäfte. In sechs Arbeitsgruppen (Meta, Operations, Actors, Affairs, Laws and Consultations) wurden Datenmodelle, -formate und -protokolle der Domäne Politische Geschäfte für alle Verwaltungsebenen standardisiert.

Im vorliegenden Anwendungsprofil eCH-0296 stehen die im Rahmen des Gesetzgebungs- und Publikationsprozesses erzeugten Dokumententypen, inbesondere Erlasse und Gesetzestexte, und deren Beziehungen untereinander im Vordergrund. Sie respektieren die im Rahmen der Fachgruppe Politische Geschäfte definierten Schemata.

1.4.1. Begrifflichkeiten

Der Begriff Gesetz ist streng genommen vom Begriff Erlass mitumfasst. Wenn man hier also von Erlassen und Gesetzestexten spricht, sind damit alle Stufen (Verfassung, Gesetze und Verordnungen) und Ausgestaltungen (Beschluss, Aufhebung, Änderung, Löschung) gemeint. Wenn im Nachfolgenden der Begriff Erlass verwendet wird, ist damit entweder der Überbegriff oder in Abgrenzung zu Gesetzen im formellen Sinn, jeder Akt eines Parlaments gemeint, der zwar rechtsetzenden Charakter hat, aber ohne materiellen Gehalt entweder ein bereits bestehendes Gesetz in Kraft setzt oder aufhebt.

Wichtig ist, dass es sich bei Gesetzen um Texte mit rechtsetzendem Charakter handelt, die Gegenstand einer juristischen Auslegung sein können, und somit auf einer semantischen Ebene mit Hilfsmaterialien (Erläuternder Bericht, Parlamentarisches Geschäft) unterlegt werden können. Diese Hilfsmaterialien als Produkt von politischen Geschäften gehören deshalb ebenfalls zu den hier definierten Dokumententypen des Gesetzgebungs- und Publikationsprozesses.

Der gesamte Gesetzgebungs- und Publikationsprozess ist ein Wechselspiel unterschiedlicher Akteure. Neben Parlamenten sind bei der Schaffung neuer und der Änderung bestehender Gesetze weitere Stakeholder wie redaktionelle Kommissionen und publizierende Organe beteiligt:

• Übersetzung: Nach einer erfolgreichen Abstimmung über den Schlussabstimmungstext im Parlament muss das Gesetz meist eine redaktionelle Bereinigung durchlaufen und wird für gewöhnlich in weitere Landessprachen übersetzt.

• Konsolidierung: Änderungen an einem Gesetz haben meistens Auswirkungen auf weitere Gesetze, was dazu führt, dass diese Auswirkungen in die neuen Fassungen konsolidiert werden müssen.

• Inkrafttreten und Referendum: Die meisten Erlasse treten erst zu einem späteren vordefinierten Zeitpunkt in Kraft. Aber auch gültig zustandegekommene Erlasse können – sofern ein Referendum zustande kommt und der Erlass vom Volk abgelehnt wird – noch vor ihrem Inkrafttreten wieder aufgehoben werden.

• Ratifikation: Sodann ist an die Ratifikation internationaler Verträge zu denken, die in einem ersten Schritt von der Exekutive oder speziellen Organen ausgehandelt und danach vom Parlament genehmigt werden müssen.

All diese Vorgänge haben zur Folge, dass ein oder mehrere Dokumente publiziert werden, welche wiederum auf andere Dokumente im Gesetzgebungs- und Publikationsprozess Bezug nehmen können. Wie diese Dokumente strukturiert sind, welche Metadaten benötigt werden um Beziehungen untereinander abzubilden, und wie diese Dokumente über einheitlich gebildete und möglichst persistente Links abgerufen werden können, ist Gegenstand dieses Standards.

1.4.2. Dokumententypen

Die folgenden Dokumententypen werden im Nachfolgenden teilweise oder vollständig als Beispiele aufgeführt:

1.4.2.1. Internationale und -kantonale Verträge

1. SR-0.101 Konvention zum Schutze der Menschenrechte und Grundfreiheiten (EMRK Europarat)

2. SR-0.111 Wiener Übereinkommen vom 23. Mai 1969 über das Recht der Verträge

3. SR-0.120 Charta der Vereinten Nationen

4. SR-0.142.112.681 Abkommen vom 21. Juni 1999 zwischen der Schweizerischen Eidgenossenschaft einerseits und der Europäischen Gemeinschaft und ihren Mitgliedstaaten andererseits über die Freizügigkeit

5. SR 413.8 Verwaltungsvereinbarung zwischen dem Schweizerischen Bundesrat und der Konferenz der kantonalen Erziehungsdirektorinnen und -direktoren über die Zusammenarbeit im Bereich der gymnasialen Maturität

6. iSR 5.3-21 Vereinbarung zwischen den Kantonen und dem Bund über die Harmonisierung der Informatik in der Strafjustiz (VHIS)

7. iSR 5.3-8 Konkordat über die Sicherheitsunternehmen

1.4.2.2. Erlasse und Gesetzestexte

1. SR-101 Federal Constitution of the Swiss Confederation — Generelle Struktur eines Erlasses auf Stufe Verfassung

2. SR-131.213 Verfassung des Kantons Luzern — Kantonsverfassung, § anstatt Artikel

3. SR-220 Obligationenrecht (OR) — Kodifikation, 5. Titel des Zivilgesetzbuches

4. SR-171.10 Parlamentsgesetz (ParlG) — Gesetz neueren Datums

5. SR-741.21 Signalisationsverordnung (SSV) — Verordnung, Tabellen und Bilder

1.4.2.3. Vernehmlassungen und Erläuternde Berichte

1. SR ? Vorentwurf zum Kommunikationsplattformengesetz (VE-KomPG)

2. AS ? Erläuternder Bericht zum VE-KomPG

3. ? Regulierungsfolgenabschätzung zum KomPG

1.4.2.4. Parlamentarische Geschäfte

1. FGA 2026/802 Schlussabstimmungstext (Vorlage der Redaktionskommission) mit Referendumsfrist

2. ? Gesetzesentwürfe und Normenkonzepte

3. ? Anträge

4. ? Fahnen (Synoptische Darstellungen)

5. ? Kommissionsberichte

1.5. Grundlagen

Die Ausführungen zu den technischen und konzeptionellen Grundlagen werden für das weitere Verständnis der normativen Kapitel vorausgesetzt, sind aber rein informativer Natur.

1.5.1. Technische Grundlagen (XML)

AKN ist ein XML Standard. Damit ist XML das technologische Fundament für AKN und AKN4CH. Jedes XML Dokument beginnt mit der Zeile <?xml version="1.0" encoding="UTF-8"?> mit Informationen zur XML-Version (1.0) und zum Zeichensatz (UTF-8).

Elemente und Attribute lassen sich in XML grundsätzlich frei definieren, dies im Gegensatz zu HTML wo gewisse Elemente vorausgesetzt werden (Beispiele: <a> oder <p>). AKN gibt ebenfalls standardisierte XML Elemente und Attribute vor, die in vordefinierten Dokumententypen vorkommen dürfen.

AKN4CH geht einen Schritt weiter und definiert eine begrenzte Auswahl an erlaubten AKN Elementen und Attributen sowie Regeln zur Strukturierung der erlaubten Dokumententypen. Ein beliebiges AKN4CH Dokument folgt dabei stets demselben Aufbau:

<?xml version="1.0" encoding="UTF-8"?> <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0"    xmlns:akn4ch="http://legaldocml.ch/">    <documentType>        <meta>            <!-- Metadata -->        </meta>        <body>            <!-- Content -->        </body>    </documentType></akomaNtoso>

1. Das Root-Element <akomaNtoso> lässt erkennen, dass es sich um ein AKN Dokument handelt.

   • Das zugehörige Attribut xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0" legt den Namespace des Dokumentes fest und bewirkt, dass alle darauffolgenden Elemente und Attribute den Regeln des Akoma Ntoso Standards in der Version 3.0 gehorchen müssen.

   • Der Präfix xmlns:akn4ch="http://legaldocml.ch/" erweitert den AKN Namespace mit spezifischen Eigenheiten für Schweizer Rechtsdaten: AKN4CH schränkt die Wahlfreiheit innerhalb von AKN weiter ein, indem es die möglichen Dokumententypen, deren Struktur und Metadaten für die Schweiz einheitlich definiert.

2. Das Element <documentType> gibt es so nicht — es handelt sich um einen Platzhalter für Dokumententypen wie z.B. <act> (für Gesetze) oder <bill> (für Gesetzesentwürfe). Der Dokumententyp bestimmt die Struktur indem es die erlaubten Elemente innerhalb des AKN- und AKN4CH-Namespace definiert.

   • Das <meta> Element enthält wichtige Metadaten zur Identifizierung, wie URI, Datum, Autor, Land, Nummer, Name, Abkürzung, Sprache und Format, sowie weitere Metadaten zum Gesetzgebungs- und Publikationsprozess.

   • Das <body> Element enthält die eigentlichen Inhalte des Dokuments, die für den Nutzer sichtbar sind, wie Artikel, Abschnitte und andere Strukturelemente.

Diese XML Dokumente können als Ausgangsformat für andere Dateiformate benutzt werden.

1.5.2. Konzeptionelle Grundlagen (FRBR)

[FRBRoo] steht für Functional Requirements of Bibliographical Records. Darin wird ein abstraktes Werk und seine sprachlichen Fassungen von einer konkreten Veröffentlichung in einem Format konzeptionell getrennt.

In FRBR werden vier Abstraktionsstufen definiert:

1. Work

2. Expression

3. Manifestation

4. Item

Beispiel: Die Bundesverfassung der Schweizerischen Eidgenossenschaft vom 12. September 1848 hat seither zahlreiche Veränderungen erfahren und ist mit der heute gültigen Version vom 18. April 1999 nicht mehr vergleichbar. Zudem sind mehrere sprachliche Versionen und unterschiedliche Dateiformate denkbar.

Sowohl AKN als auch ELI bedienen sich dieses konzeptionellen Modells. AKN4CH Dokumente sind XML Dateien und damit Manifestationen. Jedes AKN4CH Dokument enthält Metadaten zur eindeutigen Identifikation des abstrakten Werks, der sprachlichen Fassung und des Dateiformats: URI, Datum, Autor, Land, Nummer, Name, Abkürzung, Sprache und Format.

<?xml version="1.0" encoding="UTF-8"?><akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0"    xmlns:akn4ch="http://legaldocml.ch/">    <documentType>        <meta>            <identification>                <FRBRWork>                    <!-- Metadaten zur eindeutigen Identifikation des abstrakten Werks: URI, Datum, Autor, Land, Nummer, Name, Abkürzung -->                    <!-- ... -->                    <FRBRauthoritative value="true" />                </FRBRWork>                <FRBRExpression>                    <!-- Metadaten zur eindeutigen Identifikation der konkreten Fassung eines Werks: URI, Datum, Autor + Sprache -->                    <!-- ... -->                    <FRBRlanguage language="de" />                </FRBRExpression>                <FRBRManifestation>                    <!-- Metadaten zur eindeutigen Identifikation der konkreten Veröffentlichung einer Fassung eines Werks: URI, Datum, Autor + Format -->                    <!-- ... -->                    <FRBRformat value="xml" />                </FRBRManifestation>            </identification>        </meta>        <body>            <!-- Content -->        </body>    </documentType></akomaNtoso>

Darüber hinaus gibt <FRBRauthoritative value="true" /> an, ob es sich um die massgebende Fassung handelt, welche Rechtswirkungen entfaltet, wenn es mehrere unterschiedliche Fassungen in unterschiedlichen Sammlungen gibt.

2. Identifier

2.1. Einleitung

2.1.1. ELI HTTP URI Vorlage

Der digitale Austausch von Rechtsdaten zwischen Verwaltungsebenen erfordert Kenntnisse über den Speicherort und Eigenheiten des Rechtssystems. Kenntnis über den Speicherort erlangt man

AKN4CH folgt dem ELI Standard und nutzt zur Identifikation von Rechtstexten HTTP URIs. Die URIs werden formell über maschinenlesbare URI-Schematafeln beschrieben ([RFC6570]).

ELI URIs bestehen aus hierarchisch aufgebauten Komponenten, die entsprechend den nationalen Anforderungen ausgewählt werden können. Komponenten werden in der Regel durch "/" voneinander getrennt, wodurch sie in ihrer Gesamtheit einen Pfad bilden, der sowohl aus Endnutzer- als auch aus rechtlicher Perspektive eine semantische Bedeutung tragen kann. ELI empfiehlt die Nutzung der vorgeschlagenen Referenz-Komponenten, welche – mit Ausnahme der ersten "eli" Komponente – optional sind und in keiner vordefinierten Reihenfolge aneinandergereiht werden können.

Das folgende Beispiel macht sich alle der vorgeschlagenen Referenz-Komponenten in der vorgeschlagenen Reihenfolge zu Nutze: /eli/{jurisdiction}/{agent}/{subagent}/{year}/{month}/{day}/{type}/{subtype}/{domain}/{natural identifier}/{level 1…}/{point in time}/{version}/{language}

Die Referenz-Komponenten lassen sich in vier Gruppen aufteilen: Jurisdiction, Reference, Subdivision und Point in time. Zusätzlich wird zwischen einer massgebenden und konsolidierten (Version) sowie unterschiedlichen sprachlichen Fassungen (Language) unterschieden. Insbesondere Gliederungsebenen innerhalb eines Dokuments (Subdivision) und der Umgang mit Korrigenda (Subtype) werden hier ausgeblendet, da bei AKN4CH die Dokumentenperspektive im Vordergrund steht.

Für die Festlegung der AKN4CH URI-Vorlage stehen vor allem folgende Komponenten-Gruppen im Vordergrund:

• Jurisdiction (i.w.S.): Bei mehreren publizierenden Stellen muss zunächst klargestellt werden, welchem Gemeinwesen ein Rechtstext zugeordnet wird (Jurisdiction i.e.S.) und, sofern notwendig, welcher Akteur diesen erlassen hat (Agent bzw. Subagent).

• Reference: Zum Zweck der eindeutigen Identifikation muss ein Rechtstext referenzierbar sein. Wie das zu geschehen hat, ist von Land zu Land unterschiedlich und hängt stark von der Publikationspraxis ab. Denkbar sind Zeitangaben, Dokumententyp, Themen-Codes (Domain) und – falls notwendig – weitere Unterscheidungsmerkmale (Natural identifier).

2.1.2. URI-Vorlage und ELI Referenz-Komponenten

3. Content

In Arbeit.

4. Metadata

In Arbeit.

Hilfsmittel

Dieser Anhang enthält Hilfsmittel, die die Arbeit mit diesem Standard unterstützen. Sie sind informativer Natur und haben keinen normativen Charakter.

• Bikeshed-Konfiguration für eCH-Standards

ReSpec / Bikeshed Konfiguration für eCH Standards

ReSpec und Bikeshed sind Werkzeuge zur Erstellung von technischen Spezifikationen. Die untenstehenden Tabellen dokumentieren alle Dokumentabschnitte und Beilagen — ihre IDs, Klassen und Quellen.

Boilerplate-Abschnitte

eCH-0003 ("Prozessstandard eCH-Dokumente", v11.1.0) definiert die Pflichtstruktur aller eCH-Standards.

Abschnitt	id / class	Quelle
		Bikeshed	eCH
Zusammenfassung Abstract	id="abstract"	✓	✓
Stand dieses Dokuments Status of This Document	id="sotd"	✓	✓
Inhaltsverzeichnis Table of Contents	id="toc"	✓	✓
Konformität Conformance	id="conformance"	✓	✓
Einleitung Introduction	id="einleitung"	✗	✓
Sicherheitsüberlegungen Security Considerations	id="security"	✗	✓
Haftungsausschluss Disclaimer	id="disclaimer"	✗	✓
Urheberrechte Copyright	id="copyright"	✗	✓
Mitarbeit und Überprüfung Contributors	id="contributors"	✗	✓
Glossar Glossary	id="glossar"	✗	✓
Tabellenverzeichnis Table of Tables	id="tot"	✗	✓
Änderungen gegenüber Vorversion Changelog	id="changelog"	✗	✓
Beilagen Appendices	id="appendices"	—	—
Referenzen References	id="references"	✓	✓

Schlüssel	Typ	Verwendung
Title	string	Dokumenttitel.
Shortname	string	Kurzbezeichnung für URLs und Querverweise (z.B. akn4ch).
Status	string	UD rendert das Dokument als "Unofficial Proposal Draft".
Editor	string	Redakteur: Name, Organisation URL, persönliche URL.
Date	string	Offizielle Publikationsversion (ISO 8601).
Abstract	string	Kurzbeschreibung des Standards.
Max ToC Depth	number	Maximale Gliederungstiefe im Inhaltsverzeichnis.
Local Boilerplate	boolean set	Lokale Überschreibung von Boilerplate-Dateien (z.B. abstract yes, logo yes).
Boilerplate	boolean set	Deaktivierung von Boilerplate-Abschnitten (z.B. conformance off).

Abschnittstruktur

In Bikeshed mit Markdown-Modus beginnen Abschnittsüberschriften mit # (erzeugt h2) für oberste Ebene, ## für h3 usw. Explizite HTML-Abschnitte mit <h2> sind direkte Top-Level-Abschnitte.

Die Nummerierung beginnt nach Zusammenfassung und Stand des Dokuments mit 1. Abschnitte mit class=no-num werden zwar im Inhaltsverzeichnis angezeigt, tragen aber keine Nummer.

Notizen, Beispiele und Hinweise

Notizen erscheinen als graue Boxen mit der Klasse div class=note.

Beispiele erscheinen als nummerierte Boxen mit der Klasse div class=example.

<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0">
  <act name="SR-220">
    <meta>
      <identification source="#editor">
        <FRBRWork>
          <FRBRthis value="/ch/federal/act/SR-220/!akn"/>
        </FRBRWork>
      </identification>
    </meta>
  </act>
</akomaNtoso>

Code und Listen

Inline-Code verwendet <code>. Mehrzeiliger Code verwendet <pre>, optional mit Syntaxhervorhebung via highlight: (bei <pre class=include-code>) oder via CSS-Klasse (xml, js, html, md).

Bilder

Bilder werden mit dem <figure>-Element eingebunden. Die Beschriftung wird mit <figcaption> definiert.

Externe Includes

Bikeshed verwendet <pre class=include>\npath: datei.md\n</pre> zum Einbinden von Markdown- und HTML-Dateien. Für Code-Dateien steht <pre class=include-code>\npath: datei.xml\nhighlight: xml\nline-numbers:\n</pre> zur Verfügung.

Tabellen

Markdown-Tabellen unterstützen kein colspan, rowspan, caption oder benutzerdefinierte Klassen. HTML-Tabellen können direkt in .md-Dateien als rohe HTML-Blöcke eingebettet werden (mit Leerzeile davor und danach). Für nummerierte Tabellen wird <figure class=table> mit <figcaption> (nach dem schliessenden </table>) verwendet. Bikeshed fügt die Beschriftung „Tabelle N – " automatisch ein.

Referenzen

Bibliographieeinträge werden in bikeshed/biblio.json gepflegt und via Prebuild-Skript in bikeshed/biblio.bs konvertiert. Zitation: [[AKN]] (informativ) oder [[!AKN]] (normativ). Normative Referenzen erscheinen unter "Normative Referenzen", informative unter "Informative Referenzen".