Activity

1. JArmandoAnaya

   added this to the P8 - OpenSCENARIO DSL Execution milestone on Jul 21, 2026
2. JArmandoAnaya

   added

   roadmapRoad to v0.0.1Road to v0.0.1

   trackingPillar tracking issuePillar tracking issue

   pillar:p8Pillar P8Pillar P8

   on Jul 21, 2026
3. JArmandoAnaya

   added sub-issues on Jul 21, 2026

   • [p8-s1] Lowering concrete scenarios to the IR #44
   • [p8-s2] Composition operators: serial, parallel, one_of #45
   • [p8-s3] Movement modifiers #46
   • [p8-s4] XML-DSL parity & DSL golden scenarios #47
4. JArmandoAnaya

   added a commit that references this issue on Jul 21, 2026

   docs(roadmap): add GitHub tracking map for the road to v0.0.1 (#48)

   ...

   86b75fe
5. JArmandoAnaya commented on Aug 2, 2026

   

   JArmandoAnaya

   on Aug 2, 2026

   ContributorAuthor

   More actions

   P8 — OpenSCENARIO DSL Execution: complete

   All four sprints are merged and their issues closed. .osc in, trace out,
   through the same runtime the XML frontend has been feeding since P4.

   Sprint	Issue	PR	Merged
   p8-s1 lowering to the IR	#44	#107, #108	b51de28, 6b4fae4
   p8-s2 composition operators	#45	#109	e3eb4c5
   p8-s3 movement modifiers	#46	#111	d404e7d
   p8-s4 parity & DSL goldens	#47	#112	9c5427c

   13 golden scenarios / 47 checkpoints (was 11/39), 1392 gtest, 194 pytest,
   32 ADRs.

   The exit criterion, verified literally

   gs12-dsl-cruise.osc and gs12-xml-cruise.xosc are the same scenario in the
   two languages, and their traces are equal byte for byte. The check is part
   of golden.py check-all, so CI asserts it on macOS, Linux and Windows on every
   push. "Two frontends, one runtime" is now a test rather than a claim.

   Building that pair caught a real divergence, which is the best evidence it was
   worth building: the DSL storyboard stops when its do directive ends (§7.6.2)
   while the XML twin ran on, so the ramp froze at 19.975 m/s against 20. The twin
   needed a Storyboard stop trigger — the only place XML can say the same thing.

   The decisions, and where they are recorded

   • ADR-0030 — lowering: the entry point is named and a lone scenario names
     itself (§7.7.2); a participant is a field deriving from std::physical_object;
     concrete means keep(field == constant); §8.7 declares no performance limits
     and lowering invents none; a remnant is reported, never approximated.
   • ADR-0031 — composition: an operator contributes exactly one thing, the
     start trigger on a phase's Event. Concrete durations are arithmetic done at
     load; a parallel join is one ConditionGroup, which is already an AND;
     one_of's alternative is an input defaulting to the first, because the
     engine has no seed machinery and a hidden input is what determinism forbids.
   • ADR-0032 — modifiers: every §8.9 modifier lands on an action P2/P5 already
     implements, or is reported. The at anchor decides how, and at: end needs
     the phase length p8-s2 fixes. keep_speed/keep_position lower to nothing
     on purpose.

   What the DSL does not execute, and why

   Reported with a §-citation, never approximated: emit/wait @event/on/
   until (§7.6.2.5's events have no runtime carrier), along/along_trajectory
   (a concrete route comes only from §8.12.2's map methods, which the standard says
   may be external — §7.3.7.4), acceleration (no acceleration-target action in
   the IR), distance (bounds a phase by distance, sequencing is by time), the
   seven non-default parallel overlaps, and any value that would need a solver
   (ADR-0004). The DSL coverage matrix lists each with its reason.

   Standards defects found along the way

   Recorded in docs/user-guide/one-scenario-two-languages.md and the coverage
   matrix: the three §8.8/§8.9 name collisions, the two §8.15 contradictions, the
   absent performance limits, animal's missing taxonomy counterpart, and
   implementation-defined entry-point selection.

   Two defects on our side surfaced too, and both are fixed:
   enum!member resolved only in the current namespace and never through the use
   list (§7.7.4.2), which silently made every enum-valued keep look like one
   needing a solver; and the .. range operator, which never lexed at all —
   §7.2.2.6.7 spells [a '..' b] while a float's leading digits are optional, so
   [2..4] was a race the operator lost. The lexer and the parser agreed with each
   other on a spelling the standard does not have, so every range in the suite was
   written wrong and nothing noticed until duration: [10s..30s].

   One is filed rather than fixed: #110, contextual resolution of an overloaded
   enum literal (§7.3.3). It blocks nothing — the qualified spelling works — but a
   scenario copied out of the specification may need the literal qualified.

   Left open per repo convention.