should armId types be emitted as azcore/arm.ResourceID

[jhendrixMSFT]

It's currently emitted as a string for back-compat with OpenAPI.

[jhendrixMSFT]

@tadelesh do you know how the OpenAPI->tsp converted will handle converting arm-id?

[jhendrixMSFT]

Related: #914

[tadelesh]

For m4 "arm-id" type, converter will convert it to ResourceIdentifier

[jhendrixMSFT]

We could add a switch to generate using arm.ResourceID instead of *string. It has to be opt-in in order to not introduce breaking changes.

[serbrech]

+1
I would support this change, from an RP perspective.
we parse ids into arm.ResourceID often, and that means handling the error.
I would opt-in, and refactor our code if this was included.

@matthchr @jim-minter FYI

[matthchr]

I'm not opposed to this idea (I added the x-ms-arm-id-details extension + format:arm-id hoping for something like this in SDKs and BICEP once the data-fidelity in the RPs API specs was there). With that said, what's the behavior going to be in the SDK if the RP violates its contract and returns a non-ARM-ID for something that should be an ARM ID?

[serbrech]

same as whatever happens today if you return a json that does not match the contract?