#93 Vergleichsmatrix: Adapter-Capabilities pro Bundesland

docs/reference/adapter-capabilities.md

@@ -0,0 +1,81 @@
+# Adapter-Capabilities: Vergleichsmatrix
+
+Stand: 2026-04-10. Automatisch aus `parlamente.py` + `bundeslaender.py` extrahiert.
+
+## Übersicht
+
+16 Bundesländer + Bundestag, alle aktiv.
+
+| BL | Adapter | WP | Suche | Fuzzy | Typ-Filter | API |
+|---|---|---|---|---|---|---|
+| **BUND** | BundestagAdapter | 21 | Server (DIP REST) + Title-Filter | Nein | Server (`f.drucksachetyp`) | REST JSON |
+| **NRW** | NRWAdapter | 18 | Server (HTML-Form) + AND-Filter | Nein | Server (`dokTyp`) | HTML POST |
+| **LSA** | PortalaAdapter | 8 | Server (eUI) + Title-Filter | Nein | Server (`ETYPF=Antrag`) | eUI 2-Step |
+| **BE** | PortalaAdapter | 19 | Server (eUI, 730d-Fenster) + Title-Filter | Nein | Client-only | eUI 2-Step |
+| **BB** | PortalaAdapter | 8 | Server (eUI) + Title-Filter | Nein | Server (`ETYPF=Antrag`) | eUI 2-Step |
+| **RP** | PortalaAdapter | 18 | Server (eUI) + Title-Filter | Nein | Server (`ETYPF=Antrag`) | eUI 2-Step |
+| **MV** | ParLDokAdapter | 8 | Server (ParlDok JSON) + Typ-Filter | Nein | Client (`type=="Antrag"`) | REST JSON |
+| **HH** | ParLDokAdapter | 23 | Server (ParlDok JSON) + Typ-Filter | Nein | Client (`type=="Antrag"`) | REST JSON |
+| **TH** | ParLDokAdapter | 8 | Server (ParlDok JSON) + Typ-Filter | Nein | Client (Substring `"Antrag"` in type) | REST JSON |
+| **SH** | StarFinderCGI | 20 | Server (CGI, `dtyp=antrag`) + Title-Filter | Nein | Server (`dtyp`) | Legacy CGI |
+| **HE** | StarWebHEAdapter | 21 | Server (eUI, VTDRS) + Title+Typ-Filter | Nein | Client (`"antrag"` in typ) | eUI 2-Step |
+| **HB** | PARiSHBAdapter | 21 | Server (PARiS-Servlet) + Typ-Filter | Nein (Thesaurus only) | Client (`"antrag"` in typ) | HTML POST |
+| **BW** | PARLISAdapter | 17 | Server (eUI, async Polling) + Title-Filter | Nein | Server (`lines.l4=Antrag`) | eUI async |
+| **BY** | BayernAdapter | 19 | **Server-Volltext (Solr)** + Typ-Filter | **Ja (Solr)** | Client (`typ=="antrag"`) | HTML Scraping |
+| **SL** | SaarlandAdapter | 17 | **Server-Volltext (Umbraco)** + Typ-Filter | Umbraco-Relevanz | Client (`DocumentType`) | REST JSON |
+| **SN** | SNEdasXmlAdapter | 8 | Statisch (manueller XML-Export) + Title-Filter | Nein | N/A | XML Import |
+
+## Such-Architekturen
+
+### Volltext-Suche server-seitig
+
+Nur **BY** (TYPO3-Solr) und **SL** (Umbraco) bieten echte Volltextsuche
+über den gesamten Dokumentkorpus. Alle anderen filtern entweder nur den
+Titel client-seitig oder nutzen eingeschränkte Server-Filter (WP + Datum).
+
+### Client-seitige Title-Filterung
+
+Die Mehrheit (portala/eUI, ParlDok, StarFinder, BUND) holt einen breiten
+Satz von Treffern nach WP/Datum/Typ und filtert dann im Python-Code per
+`all(t in title.lower() for t in query_terms)`. Das bedeutet:
+
+- **Nur Titel-Matches** — Inhalte der Drucksachen werden nicht durchsucht
+- **AND-Logik** — alle Suchbegriffe müssen im Titel vorkommen
+- **Keine Fuzzy-Toleranz** — Tippfehler oder Synonym-Drift werden nicht abgefangen
+- **Performance ok** — max. 1000-1500 Treffer pro Request (via chunksize)
+
+### Sonderfälle
+
+| BL | Besonderheit |
+|---|---|
+| **SN** | Kein Scraping möglich (`robots.txt`); manueller wöchentlicher XML-Export aus EDAS |
+| **BE** | `document_type=None` weil Berlin's ETYPF andere Values nutzt; 730-Tage-Fenster als Workaround |
+| **TH** | Anträge heißen "Antrag gemäß § 79 GO" → Substring-Match statt Exact-Match; `kinds=["Drucksache", "Vorlage"]` |
+| **BW** | Async 2-Step mit Search-ID-Polling (2-15 Versuche × 2s Pause), JSON-in-HTML-Comments |
+| **HE** | Perl-Data::Dumper in HTML-Comments, Hex-Escape-Decoding (`\x{e9}` → `é`) |
+| **NI** | ❌ **Nicht implementiert** — NILAS-StarWeb braucht Session-Cookie, HAR-Capture nötig |
+
+## Historien-Tiefe (ältere WPs)
+
+Alle Adapter sind aktuell auf **eine feste Wahlperiode** konfiguriert.
+Keiner unterstützt Queries über mehrere WPs hinweg. Ältere Drucksachen
+aus früheren WPs sind nicht abrufbar ohne Adapter-Rekonfiguration.
+
+Für eine künftige Multi-WP-Suche müsste pro Adapter geprüft werden, ob
+das Backend WP-übergreifende Queries unterstützt:
+
+| API-Typ | Multi-WP möglich? |
+|---|---|
+| portala/eUI | Ja (WP-Term aus dem JSON-Tree weglassen) |
+| ParlDok | Ja (`facet_lp` weglassen) |
+| StarFinder/PARiS | Ja (WP-Param weglassen) |
+| TYPO3-Solr (BY) | Ja (`wahlperiodeid[]` weglassen) |
+| DIP-API (BUND) | Ja (`f.wahlperiode` weglassen) |
+| Umbraco (SL) | Ja (`Filter.Periods=[]`) |
+| EDAS-XML (SN) | Nur innerhalb des exportierten Datenbestands |
+
+## Fehlende Adapter
+
+| BL | Status | Blocker |
+|---|---|---|
+| **NI** (Niedersachsen) | Issue #22 offen | NILAS-StarWeb erfordert Session-Cookie, HAR-Capture vom User nötig |

mkdocs.yml

@@ -22,6 +22,8 @@ nav:
     - "0002 Adapter-Architektur": adr/0002-adapter-architecture.md
     - "0003 Citation-Property-Tests": adr/0003-citation-property-tests.md
     - "0004 Deployment-Workflow": adr/0004-deployment-workflow.md
+  - Reference:
+    - Adapter-Capabilities: reference/adapter-capabilities.md
   - Archiv:
     - Übersicht: archive/index.md