Multivalued inlined populated_from paths don't fan out per-item to a matching class_derivation

[amc-corey-cox]

Follow-up to #247 (which lands slot-level inline dot-path traversal for scalar leaves).

A multivalued inlined path like populated_from: dataset.dataTable should fan out: each item in the list is mapped through the class_derivation whose target matches the slot's range, EML-style:

class_derivations:
  SchemaDefinition:
    populated_from: EMLDocument
    slot_derivations:
      classes:
        populated_from: dataset.dataTable   # multivalued inline list
  ClassDefinition:                            # should auto-fire per dataTable item
    populated_from: DataTable
    slot_derivations:
      name:
        populated_from: entityName

Today no dispatch exists for this. _derive_nested_objects only handles slot derivations that embed class_derivations: directly, and maps once per nested CD on a single (joined) row — it does not iterate a list of source items. This needs new range-matched, per-item fan-out orchestration on top of the slot-level inline traversal from #247.

Slot-level inline traversal (#247) raises a clear diagnostic naming the multivalued segment and pointing here, rather than silently returning None, until this lands.

[github-actions]

Summary (auto-generated)

What this issue is about

This is the second half of the inlined dot-path story. Issue #247 (still open) landed scalar traversal for inlined nested data — so populated_from: dataset.title now works when dataset is an embedded object rather than an FK reference. This issue covers the remaining case: when the terminal segment of the dot-path is a multivalued (list) inlined slot, the engine must fan out per list item through the class_derivation whose populated_from matches the slot's range type. That dispatch does not exist yet.

---

The gap in concrete terms

Given a spec like:

class_derivations:
  SchemaDefinition:
    populated_from: EMLDocument
    slot_derivations:
      classes:
        populated_from: dataset.dataTable   # ← multivalued inlined list
  ClassDefinition:                          # should auto-fire once per DataTable item
    populated_from: DataTable
    slot_derivations:
      name:
        populated_from: entityName

Today _derive_nested_objects only handles slot derivations that directly embed class_derivations: inline, and it maps once per nested CD against a single (joined) row — it never iterates the source list. The needed behavior is: resolve dataset.dataTable to a Python list, then for each item look up the class_derivation whose populated_from matches the range of dataTable (i.e. DataTable → ClassDefinition), and invoke the derivation once per item.

As a temporary guard, the scalar traversal code from #247 raises a descriptive diagnostic when it encounters a multivalued segment (naming the segment and pointing here), rather than silently returning None.

---

Relationship to the surrounding issue arc

Issue	Status	Relation
#212 — FK-join dot-paths	Closed	Foundation: implicit cross-table join via ObjectIndex
#247 — inlined scalar dot-paths	Open (v0.5.3)	Direct predecessor: adds structural walk for scalar inlined leaves; raises the diagnostic that points here
#236 — populated_from_descendants	Open	Complementary: finds all instances of a class anywhere in the tree without knowing the path. This issue is "follow a known structural path". Both needed for EML importer.
#216 — parent-context derivations	Open	Adjacent but orthogonal: synthesising a nested target from a flat source parent
schema-automator#208 — EML importer	Open	Primary consumer; currently works around both #247 and #265 with a manual Python loop over dataset.dataTable[]

---

Milestone context

This issue is filed under v0.5.3 ("patch release completing the PV deprecation arc, validate-spec / orchestration polish, extension surface, and sparse-join correctness"). It is the last piece of the inlined-path traversal work: #247 handles scalars, #265 handles multivalued lists. Together they let the EML importer (and future XSD / JSON-Schema importers) replace their hand-written iteration loops with fully declarative class_derivations.

---

Implementation sketch

The change is in the orchestration layer of ObjectTransformer, not in the per-slot resolution logic from #247. When a slot derivation's resolved populated_from value is a list:

1. Detect that the range class (DataTable in the example) has a matching class_derivation (ClassDefinition).
2. Iterate the list; for each item, invoke that class_derivation with the item as the source object.
3. Collect the results into the target slot.

The per-segment traversal introduced in #247 already delivers the list to the orchestrator; the gap is purely in step 1–3 above.