DESCRIBE IMPORT MAPPING output does not round-trip: ExposedName still capitalised and Item-suffixed on v0.18.0 (follow-up to #882)

[MendixMau]

Summary

#882 ("CREATE IMPORT MAPPING does not persist the JSON member names it is given") was closed as completed on 2026-08-13. The runtime-critical half is genuinely fixed — the stored JsonPath now preserves the original JSON keys verbatim. Thank you.

What still reproduces on v0.18.0 is the other half: ExposedName is still capitalised and still gets an Item suffix on array bindings, and DESCRIBE IMPORT MAPPING renders ExposedName rather than the JSON member name. So describe output no longer matches the script that produced it, and does not round-trip.

This is a much smaller bug than #882 as originally reported — no runtime breakage that I can demonstrate — so I am filing it separately rather than reopening.

Environment

mxcli	v0.18.0 (2026-08-14T20:29:13Z), official darwin-arm64 release binary
Mendix	11.12.0
OS	macOS 15 (Darwin 25.6.0), arm64

Reproduction

create json structure "B"."JS_Lower"
  snippet $${ "total": 1, "camelCase": "x", "item": [ { "name": "a" } ] }$$;

create non-persistent entity "B"."LRoot" ( "Total": Integer, "Camel": String(200) );
create non-persistent entity "B"."LItem" ( "Nm": String(200) );
create association "B"."LItem_LRoot" from "B"."LItem" to "B"."LRoot" type reference owner default;

create import mapping "B"."IMM_Lower" with json structure "B"."JS_Lower"
{
  create B.LRoot {
    Total = total,
    Camel = camelCase,
    create B.LItem_LRoot/B.LItem = item {
      Nm = name
    }
  }
};

Then: mxcli -p app.mpr -c "DESCRIBE IMPORT MAPPING B.IMM_Lower"

Actual

create import mapping B.IMM_Lower
  with json structure B.JS_Lower
{
  create B.LRoot {
    Total = Total,                                  <-- source said: total
    Camel = CamelCase,                              <-- source said: camelCase
    create B.LItem_LRoot/B.LItem = ItemItem {       <-- source said: item
      Nm = Name                                     <-- source said: name
    }
  }
};

Re-executing this describe output is not equivalent to the original script.

What the stored BSON shows

Decoded from the mapping's .mxunit (plain uncompressed BSON), same mapping, authored by v0.18.0:

ExposedName values:  Root, Total, CamelCase, ItemItem, Name
JsonPath values:     (Object)
                     (Object)|total
                     (Object)|camelCase
                     (Object)|item|(Object)
                     (Object)|item|(Object)|name

JsonPath is correct on every element — original casing preserved, no Item suffix. Only ExposedName is transformed, and DESCRIBE renders ExposedName.

Note the array suffix is unconditional, so it can collide: a JSON member literally named item becomes ItemItem, and (as in #882) __Value becomes __ValueItem.

Expected

Either ExposedName should hold the JSON member name as given, or DESCRIBE IMPORT MAPPING should render JsonPath's member name so that its output round-trips.

What I have not established

Whether ExposedName is load-bearing at runtime. Given JsonPath is correct I would expect not, but I could not run the app on this machine to confirm (macOS mxbuild issue, unrelated). If ExposedName is purely cosmetic then this is a describe/round-trip bug only, which is how I have titled it.

[MendixMau]

Correction to my own report — one of the two claims above does not hold up, and I would rather flag it than leave it standing.

ExposedName capitalisation is normal Mendix behaviour, not a defect. I checked mxcli-authored mappings against Studio-Pro-authored ones in an unrelated project, reading the stored BSON of both. Studio Pro capitalises exactly the same way:

Studio-Pro-authored mapping:
  ExposedName = StopReason      JsonPath = (Object)|stopReason
  ExposedName = InputTokens     JsonPath = (Object)|usage|inputTokens

So mxcli writing Total for total matches what Studio Pro does, and my framing of this as "#882's fix is incomplete" was wrong. I withdraw that part, and with it the implication that anything regressed.

What I still think stands is the narrower round-trip point in the title: DESCRIBE IMPORT MAPPING renders ExposedName, so its output is not the script that produced it, and re-executing the describe output is not equivalent to the original. For a describe → edit → re-exec workflow that is a real problem, whatever the stored value's provenance:

source:   create B.LItem_LRoot/B.LItem = item { Nm = name }
describe: create B.LItem_LRoot/B.LItem = ItemItem { Nm = Name }

Rendering the member name from JsonPath instead of ExposedName would fix that, and would leave the stored model untouched.

Feel free to retitle or downscope this issue accordingly — as filed it overstates the case.