|
| 1 | +# Design: Schema Validation Monitoring |
| 2 | + |
| 3 | +## Architecture Overview |
| 4 | + |
| 5 | +This change introduces automated monitoring of structural dependencies (HTML parsing, XML schema) through lightweight scheduled validation and issue reporting. |
| 6 | + |
| 7 | +``` |
| 8 | +┌─────────────────────────────────────────────────────────────┐ |
| 9 | +│ GitHub Actions │ |
| 10 | +│ ┌───────────────────────────────────────────────────────┐ │ |
| 11 | +│ │ schema-validation.yml (weekly schedule) │ │ |
| 12 | +│ │ │ │ |
| 13 | +│ │ 1. Checkout code │ │ |
| 14 | +│ │ 2. Setup Python │ │ |
| 15 | +│ │ 3. Run schema tests ──────────────┐ │ │ |
| 16 | +│ │ 4. Parse results │ │ │ |
| 17 | +│ │ 5. Create issue if failed ────────┼──────┐ │ │ |
| 18 | +│ └────────────────────────────────────┼──────┼───────────┘ │ |
| 19 | +└───────────────────────────────────────┼──────┼───────────────┘ |
| 20 | + │ │ |
| 21 | + ┌─────────────────────┘ │ |
| 22 | + │ │ |
| 23 | + ▼ ▼ |
| 24 | + ┌──────────────────────────┐ ┌──────────────────────┐ |
| 25 | + │ test_schema_ │ │ GitHub Issues API │ |
| 26 | + │ validation.py │ │ │ |
| 27 | + │ │ │ Title: Schema │ |
| 28 | + │ 4 tests (~1min): │ │ validation │ |
| 29 | + │ - HTML params OK? │ │ failed │ |
| 30 | + │ - XML namespace OK? │ │ Assignee: aborruso │ |
| 31 | + │ - XML elements OK? │ │ Labels: bug, auto │ |
| 32 | + │ - Download OK? │ │ │ |
| 33 | + └──────────┬───────────────┘ └──────────────────────┘ |
| 34 | + │ |
| 35 | + ▼ |
| 36 | + ┌──────────────────────────┐ |
| 37 | + │ normattiva.it │ |
| 38 | + │ (single sample doc) │ |
| 39 | + │ │ |
| 40 | + │ - Download HTML page │ |
| 41 | + │ - Extract params │ |
| 42 | + │ - Download XML │ |
| 43 | + │ - Verify schema │ |
| 44 | + └──────────────────────────┘ |
| 45 | +``` |
| 46 | + |
| 47 | +## Key Design Decisions |
| 48 | + |
| 49 | +### 1. Test Scope: Schema Only, Not Full Conversion |
| 50 | +**Decision**: Validate only HTML parsing and XML schema, skip Markdown conversion |
| 51 | + |
| 52 | +**Rationale**: |
| 53 | +- Focused validation: catches the actual breaking points (external dependencies) |
| 54 | +- Fast execution: < 1 minute, suitable for weekly schedule |
| 55 | +- Fewer false positives: conversion bugs are separate from schema changes |
| 56 | +- Clear diagnostics: failure points to specific structural change |
| 57 | + |
| 58 | +**Alternatives Considered**: |
| 59 | +- Full conversion testing → rejected (too slow, too many failure modes) |
| 60 | +- Only unit tests → rejected (doesn't detect normattiva.it changes) |
| 61 | +- Manual monitoring → rejected (requires human attention) |
| 62 | + |
| 63 | +### 2. Single Sample Document |
| 64 | +**Decision**: Test against one representative legal document (CAD decree) |
| 65 | + |
| 66 | +**Rationale**: |
| 67 | +- Sufficient coverage: one document exercises all structural dependencies |
| 68 | +- Fast execution: single download + parse |
| 69 | +- Stable baseline: same document enables change detection |
| 70 | +- Easy debugging: consistent test case |
| 71 | + |
| 72 | +**Alternatives Considered**: |
| 73 | +- Multiple documents → rejected (unnecessary, schema is uniform) |
| 74 | +- Random selection → rejected (non-deterministic) |
| 75 | +- All test_data/ files → rejected (doesn't test live download) |
| 76 | + |
| 77 | +### 3. Issue Creation Strategy |
| 78 | +**Decision**: Create one issue per failed workflow run with all failures grouped |
| 79 | + |
| 80 | +**Rationale**: |
| 81 | +- Single notification: maintainer gets one alert, not spam |
| 82 | +- Context preservation: all related failures in one place |
| 83 | +- Easy tracking: one issue to close when fixed |
| 84 | +- Workflow correlation: issue links directly to failed run |
| 85 | + |
| 86 | +**Alternatives Considered**: |
| 87 | +- One issue per failed test → rejected (too noisy, 5+ issues per run) |
| 88 | +- Update existing open issue → rejected (hard to track historical failures) |
| 89 | +- Slack/email notification → rejected (GitHub-native is simpler) |
| 90 | + |
| 91 | +### 4. Validation Criteria |
| 92 | +**Decision**: Four focused validation points (HTML params, XML namespace, XML elements, download) |
| 93 | + |
| 94 | +**Rationale**: |
| 95 | +- HTML parameter extraction: detects normattiva.it HTML structure changes |
| 96 | +- XML namespace: verifies Akoma Ntoso 3.0 compatibility |
| 97 | +- Essential XML elements: ensures required structure present |
| 98 | +- Download success: catches API/network issues |
| 99 | + |
| 100 | +**What to validate**: |
| 101 | +```python |
| 102 | +1. HTML parameter extraction: |
| 103 | + - dataGU found in hidden input |
| 104 | + - codiceRedaz found in hidden input |
| 105 | + - dataVigenza found in hidden input (optional) |
| 106 | + - Values are non-empty |
| 107 | + |
| 108 | +2. XML namespace: |
| 109 | + - Akoma Ntoso 3.0 namespace present |
| 110 | + - Namespace URL unchanged |
| 111 | + |
| 112 | +3. Essential XML elements: |
| 113 | + - <akomaNtoso> root element exists |
| 114 | + - <meta> section exists |
| 115 | + - <body> section exists |
| 116 | + - At least one <article> exists |
| 117 | + |
| 118 | +4. Download success: |
| 119 | + - HTTP 200 status |
| 120 | + - Response is parseable XML |
| 121 | + - Not HTML error page |
| 122 | +``` |
| 123 | + |
| 124 | +### 5. Workflow Schedule |
| 125 | +**Decision**: Weekly on Monday 09:00 UTC with manual trigger option |
| 126 | + |
| 127 | +**Rationale**: |
| 128 | +- Weekly frequency: balances monitoring vs noise (not too frequent) |
| 129 | +- Monday morning: gives full week to address issues |
| 130 | +- UTC timezone: clear reference time |
| 131 | +- Manual trigger: allows on-demand validation before releases |
| 132 | + |
| 133 | +**Alternatives Considered**: |
| 134 | +- Daily → rejected (too frequent, alert fatigue) |
| 135 | +- After each commit → rejected (not integration test purpose) |
| 136 | +- Monthly → rejected (too infrequent, delays problem detection) |
| 137 | + |
| 138 | +## Error Handling |
| 139 | + |
| 140 | +### Test Failures |
| 141 | +- Each test is independent, failures don't stop execution |
| 142 | +- All failures collected and reported together |
| 143 | +- Stack traces captured for debugging |
| 144 | + |
| 145 | +### Network Failures |
| 146 | +- Retry mechanism for transient failures (3 attempts, 5s backoff) |
| 147 | +- Distinguish between network errors vs structural changes |
| 148 | +- Report network failures separately from conversion errors |
| 149 | + |
| 150 | +### Issue Creation Failures |
| 151 | +- Workflow doesn't fail if issue creation fails |
| 152 | +- Log error to workflow output |
| 153 | +- Maintainer still sees workflow failure in GitHub UI |
| 154 | + |
| 155 | +## Testing Strategy |
| 156 | + |
| 157 | +### Local Testing |
| 158 | +```bash |
| 159 | +# Run all schema validation tests |
| 160 | +pytest tests/test_schema_validation.py -v |
| 161 | + |
| 162 | +# Test HTML parameter extraction only |
| 163 | +pytest tests/test_schema_validation.py::TestSchemaValidation::test_html_parameter_extraction -v |
| 164 | + |
| 165 | +# Test XML schema only |
| 166 | +pytest tests/test_schema_validation.py::TestSchemaValidation::test_xml_namespace_stable -v |
| 167 | +pytest tests/test_schema_validation.py::TestSchemaValidation::test_xml_essential_elements -v |
| 168 | +``` |
| 169 | + |
| 170 | +### Workflow Testing |
| 171 | +1. Manual trigger with success scenario |
| 172 | +2. Temporarily break HTML parsing, verify issue created |
| 173 | +3. Revert break, verify issue closure (if implemented) |
| 174 | +4. Wait for scheduled run (first Monday) |
| 175 | + |
| 176 | +## Performance Considerations |
| 177 | + |
| 178 | +- Target execution time: < 1 minute |
| 179 | +- Single document test |
| 180 | +- Minimal computation: parse HTML, validate XML structure |
| 181 | +- No Markdown conversion (saves time) |
| 182 | +- No heavy analysis |
| 183 | + |
| 184 | +## Future Enhancements (Not in Scope) |
| 185 | + |
| 186 | +1. **Multiple Sample Documents**: Test against 3-5 different document types |
| 187 | +2. **Historical Tracking**: Store validation results over time, trend analysis |
| 188 | +3. **Auto-Recovery**: Retry with different parameters if extraction fails |
| 189 | +4. **Full Conversion Testing**: Add optional full MD conversion validation |
| 190 | +5. **Performance Benchmarking**: Track download/parse speed over time |
0 commit comments