Mark NWS forecast discussion resilience implemented
This commit is contained in:
@@ -2,13 +2,12 @@
|
||||
|
||||
## Status
|
||||
|
||||
The original ellipsis-first and slash-qualified heading feature is implemented.
|
||||
The resilience follow-up defined below is proposed and unimplemented.
|
||||
Implemented.
|
||||
|
||||
## Completed Baseline
|
||||
## Implemented Behavior
|
||||
|
||||
The NWS Area Forecast Discussion parser now recognizes these heading families
|
||||
for key messages, short term, long term, and aviation:
|
||||
The NWS Area Forecast Discussion parser recognizes these heading families for
|
||||
all structurally valid section identities:
|
||||
|
||||
```text
|
||||
.<SECTION>...<optional qualifier>
|
||||
@@ -18,42 +17,19 @@ for key messages, short term, long term, and aviation:
|
||||
Discovery, qualifier extraction, and recognized-section boundary detection use
|
||||
one provider-specific parser. Slash delimiters are removed from qualifiers,
|
||||
legacy qualifier text is preserved, and aviation remains a boundary rather than
|
||||
a canonical field. Focused provider and normalizer regressions cover the
|
||||
implemented forms.
|
||||
a canonical field.
|
||||
|
||||
## Remaining Problem
|
||||
|
||||
Current NWS bulletins vary beyond those two same-line forms. In particular:
|
||||
|
||||
- an ellipsis-first heading may put its qualifier on the next nonblank line;
|
||||
- NWS presentation output can place `-- Changed Discussion --` markers and an
|
||||
`Updated at` line around section content;
|
||||
- valid AFDs can include `DISCUSSION`, `UPDATE`, `MARINE`, `HYDROLOGY`,
|
||||
`CLIMATE`, `FIRE WEATHER`, office watch/advisory blocks, and other topic
|
||||
headings; and
|
||||
- minor punctuation or qualifier changes can produce headings that are
|
||||
structurally valid but absent from the parser's identity whitelist.
|
||||
|
||||
The current parser recognizes only four exact identities. Unknown headings do
|
||||
not terminate the preceding section. It also expects a text section's optional
|
||||
qualifier and `Issued at` line in a narrow order. Consequently, valid upstream
|
||||
format variants can leave qualifier and section-time fields empty, leak
|
||||
presentation metadata into prose or key messages, or allow one section to
|
||||
absorb another.
|
||||
|
||||
## Feature Objective
|
||||
|
||||
Make AFD parsing resilient to minor upstream format evolution by separating:
|
||||
The parser separates:
|
||||
|
||||
1. generic structural heading recognition;
|
||||
2. section boundary scanning;
|
||||
3. canonical section-role selection; and
|
||||
4. section-preamble and presentation cleanup.
|
||||
|
||||
The parser should accept new structurally valid topic names as safe boundaries
|
||||
without treating them as new canonical fields.
|
||||
Structurally valid topic names act as safe boundaries without becoming new
|
||||
canonical fields.
|
||||
|
||||
## Targeted End State
|
||||
## Implemented Details
|
||||
|
||||
### Generic heading recognition
|
||||
|
||||
@@ -135,9 +111,9 @@ A single `DISCUSSION` section and other currently unmapped identities are
|
||||
recognized as boundaries but are not forced into short- or long-term fields.
|
||||
Exposing such content would require a separate canonical schema decision.
|
||||
|
||||
## Acceptance Criteria
|
||||
## Verified Coverage
|
||||
|
||||
The resilience follow-up is complete when automated tests demonstrate that:
|
||||
Automated tests demonstrate that:
|
||||
|
||||
- every previously accepted heading and canonical result remains compatible;
|
||||
- generic structurally valid identities terminate preceding content without
|
||||
@@ -167,5 +143,5 @@ This follow-up does not:
|
||||
- change schemas, persistence contracts, configuration, or downstream APIs; or
|
||||
- fetch live NWS data during tests.
|
||||
|
||||
Canonical support for additional AFD section identities should be driven by a
|
||||
separate consumer requirement and schema roadmap.
|
||||
Additional canonical support for AFD section identities requires a separate
|
||||
consumer requirement and schema roadmap.
|
||||
|
||||
Reference in New Issue
Block a user