Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- guidelines [2024/12/12 08:10] – lars_gerulat
+++ guidelines [2026/09/08 14:38] (aktuell) – B2Base-Schemaentwurf: internationale Datenmodelle, Beispiele und Erläuterungen 0.0.0.0
@@ Zeile 1: / Zeile 1: @@
-====== Buch: Entbürokratisierung bei Diversifizierung: Geht das überhaupt? ======
+====== Entwickler-Richtlinien ======
-Dieses Buch untersucht die Möglichkeiten, Bürokratie in einer zunehmend diversifizierten und globalisierten Welt durch Technologie, Bildung und Standardisierung zu vereinfachen. Es zeigt auf, wie Werkzeuge wie BPMN, JSON und RegEx genutzt werden können, um komplexe Prozesse zu modellieren, zu automatisieren und nachhaltiger zu gestalten. Der Fokus liegt auf der intelligenten Verbindung von Vielfalt und Struktur, um Verwaltungsaufwand zu minimieren, Innovation zu fördern und gesellschaftliche Herausforderungen zu meistern. Es betont die zentrale Rolle der Bildung, um technologische Kompetenzen zu vermitteln und zukunftsfähige Systeme zu entwickeln. Gleichzeitig werden konkrete Lösungsansätze für Wirtschaft, Verwaltung und Bildung vorgestellt, die zeigen, wie Technologie und Nachhaltigkeit Hand in Hand gehen können. Ein inspirierendes Werk für alle, die Komplexität nicht als Last, sondern als Chance begreifen möchten. [[https://amzn.eu/d/cMUyg05|⇒]]
-====== JSON ======
+<WRAP b2hero>
-Die JavaScript Object Notation ist ein kompaktes Datenformat in einer einfach lesbaren Textform für den Datenaustausch zwischen Anwendungen. JSON ist von Programmiersprachen unabhängig. Parser und Generatoren existieren in allen verbreiteten Sprachen. [[https://de.wikipedia.org/wiki/JavaScript_Object_Notation|⇒]]
+**Vom Schema zur verlässlichen Datenübergabe**
+Schema auswählen, Version festhalten, Daten prüfen und erst danach fachlich verwenden.
+[[schemes:scheme|Bibliothek]] · [[:examples|Beispiele]] · [[schemes:principles|Grundregeln]]
+</WRAP>
+===== Ein Schema verwenden =====
+  - Das passende Modul aus der [[schemes:scheme|Bibliothek]] wählen und das **Austauschschema** herunterladen.
+  - Die konkrete ''$id'' und Fassung festhalten. Keine automatische Umstellung auf eine unbekannte neue Version.
+  - JSON-Daten in der beschriebenen Struktur erzeugen. JSON ist das Datenformat; JSON Schema beschreibt die Regeln dafür.
+  - Mit einem Validator für **Draft 2020-12** prüfen und benötigte Formatprüfer aktivieren. Alle lokalen ''$ref''-Verweise sind in der Datei enthalten.
+  - Anschließend Referenzziele, Registercodes, Prüfziffern, Zeitfolgen und fachliche Regeln prüfen.
+==== Beispiel mit Python ====
+Voraussetzung: Python und das Paket ''jsonschema[format]''. Dies ist ein Beispiel für einen Validator, keine zusätzliche Voraussetzung für den PHP-Workspace.
+<code python>
+import json
+from jsonschema import Draft202012Validator
+with open("money.schema.json", encoding="utf-8") as file:
+    schema = json.load(file)
+Draft202012Validator.check_schema(schema)
+validator = Draft202012Validator(
+    schema, format_checker=Draft202012Validator.FORMAT_CHECKER
+)
+validator.validate({"amount": "12.345", "currency": "KWD"})
+</code>
+Validatoren unterscheiden sich im Umfang ihrer Formatprüfer. Insbesondere internationalisierte E-Mail-Adressen, Sprachcodes und nationale Kennungen benötigen zusätzliche geeignete Prüfungen. [[https://python-jsonschema.readthedocs.io/en/stable/validate/|Dokumentation von python-jsonschema]]
+===== Im Workflowdesigner verwenden =====
+  - Auf der Schemaseite **Schema für den Designer** herunterladen.
+  - Den [[b2app>demo/editor.html|Designer]] öffnen und zum Reiter **Schema** wechseln.
+  - Die JSON-Datei importieren, ihren Inhalt einfügen oder eine direkt erreichbare JSON-URL verknüpfen. Bei einem anderen Server muss dieser CORS erlauben.
+  - Ein Feld wählen und als Formularfeld oder Speicherregel übernehmen. Bei Listen wird zunächst Index ''0'' angeboten; weitere Einträge brauchen passende Workflowlogik.
+  - Vor einer verbindlichen Übergabe den gesamten Datensatz gegen das **Austauschschema** und das fachliche Profil prüfen.
+<WRAP b2note>
+**Die Designer-Fassung ist eine Hilfe zur Feldübernahme.** Sie übernimmt unterstützte Einzelregeln und lässt bedingte Objektregeln, Listenlängen und weitere Strukturprüfungen weg. Die ausgelassenen Schema-Regeln sind zusätzlich in der versionierten ''manifest.json'' dokumentiert. Das Schema ist keine Bestätigung, dass ein vollständiger Datensatz bereits gültig ist.
+</WRAP>
+Der derzeitige Designer löst lokale ''$ref''-Verweise auf und unterstützt unter anderem Datentypen, Muster, Grenzen und Auswahllisten. Vollständige Objektvalidierung, freie Erweiterungsobjekte, beliebige ''payload.data''-Felder und zusätzliche Formate wie ''idn-email'', ''iri'' und ''date-time'' brauchen ergänzende Logik. Bei optionalen verschachtelten Modulen gelten deren Pflichtfelder erst, wenn das Modul im konkreten Ablauf erhoben wird; die Runtime prüft vor allem die gerade erfassten Felder.
+**Beispiel Speicherpfad:** Für das Modul ''person/nameandbirthdetails'' ist der Name unter ''[name][preferredName]'' erreichbar. Wird dasselbe Modul in einem zusammengesetzten Schema unter ''person'' eingebettet, lautet der Pfad ''[person][name][preferredName]''. Der Pfad hängt von der tatsächlichen Datenwurzel ab.
+**Geldbetrag:** ''[amount]'' bleibt ein String. Eine Speicherregel verwendet daher ''{string}[amount] = "12.345"''. Nicht als double speichern, wenn Dezimalgenauigkeit erhalten bleiben muss.
+===== Module zusammensetzen =====
+Zwei Objekte nebeneinander sind noch kein gemeinsames Schema. Beim Einbetten eines Moduls müssen seine lokalen Referenzen weiterhin auf die richtigen Definitionen zeigen. Entweder das vollständige Schema als eigene Ressource mit ''$id'' registrieren oder mit einem geeigneten Bundler Referenzen umschreiben. Ein bloßes Kopieren der ''properties'' verliert leicht Pflichtregeln und ''$defs''.
+Die neuen Aufgaben-, Dokument- und Übergabeschemata sind Austauschverträge. Der vorhandene Workspace verwendet seine bisherige Datenstruktur. Ein Adapter muss Werte ausdrücklich zuordnen und danach erneut validieren; das Wiki installiert keine automatische Ausführung von Skripten oder E-Mails.
+===== Einen Standard erweitern =====
+  - Fachliche Bedeutung und realen Anwendungsfall beschreiben.
+  - Gegenbeispiele aus unterschiedlichen Ländern, Schriften und Datenlagen sammeln.
+  - Gemeinsamen Kern von Länder- oder Verfahrensprofilen trennen.
+  - Gültige und ungültige Beispiele liefern; Syntax, Meta-Schema, vollständige Validierung und Designer-Felder prüfen.
+  - Änderung an Feldnamen, Bedeutung, Typen oder Pflichtangaben als Migrationsentscheidung dokumentieren.
+  - Eine freigegebene Version unverändert lassen. Neue Semantik braucht eine neue Kennung und Fassung.
+===== Pflege im Projekt =====
+Die gemeinsame Quelle liegt in ''standards/catalog.cjs''; Übersichtsseiten und Integrationshinweise in ''standards/wiki-pages.cjs''. Daraus entstehen die JSON-Dateien und die Wiki-Einträge. Dauerhafte Änderungen an generierten Seiten deshalb in diesen Quellen nachführen, sonst überschreibt der nächste Abgleich sie. Das Speichern verwendet die DokuWiki-Versionshistorie.
+<code powershell>
+node tools/build-standards.cjs
+node tools/build-standards.cjs --check
+python -m pip install -r tests/requirements-standards.txt
+python tests/wiki-standards-test.py
+node --test tests/wiki-standards.test.cjs
+php tests/wiki-render-test.php
+</code>
+Die Dateien unter ''schemas/1.0.0-draft.1/'' und die Wiki-Konfiguration für die Download-Verweise gehören gemeinsam ins Deployment. Die lokale Wiki-Installation liegt unter ''wiki/''; die Schemadateien liegen im benachbarten Ordner ''schemas/''. Das lokale Bearbeiten veröffentlicht nichts auf einer entfernten Domain.
+===== Hintergrund =====
+BPMN beschreibt den Ablauf; JSON Schema beschreibt Daten. Reguläre Ausdrücke helfen bei begrenzten Mustern, ersetzen aber keine vollständigen fachlichen Prüfungen. Weiterführender Hintergrund zum Projekt: [[https://amzn.eu/d/cMUyg05|Entbürokratisierung bei Diversifizierung: Geht das überhaupt?]].