cadl-ranch-specs, add basic test case of clientInitialization

[weidongxu-microsoft]

Cadl Ranch Contribution Checklist:

• I have written a scenario spec
• I have meaningful @scenario names. Someone can look at the list of scenarios and understand what I'm covering.
• I have written a mock API
• I have used @scenarioDocs for extra scenario description and to tell people how to pass my mock api check.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7fb502f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@azure-tools/cadl-ranch-specs	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[chunyu3]

We may need add more complex cases:

• more complex client hierarchy, e.g. more than 3 layer clients
• co-operate with @client / @operationGroup decorator
• with paramMaps to map a parameter to the property of the Client initialization Model
• a senario that not all operations has the bumped parameter

[weidongxu-microsoft]

We may need add more complex cases:

• more complex client hierarchy, e.g. more than 3 layer clients
• co-operate with @client / @operationGroup decorator
• with paramMaps to map a parameter to the property of the Client initialization Model
• a senario that not all operations has the bumped parameter

Wondering whether we need to have a subfolder for different scenarios. And this be in a "basic" folder.

As the characteristic of the "client hierarchy", some of them cannot co-exist in same main.tsp. E.g. client by namespace/interface cannot be in same file as client by @client/@operationGroup.

[chunyu3]

We may need add more complex cases:

• more complex client hierarchy, e.g. more than 3 layer clients
• co-operate with @client / @operationGroup decorator
• with paramMaps to map a parameter to the property of the Client initialization Model
• a senario that not all operations has the bumped parameter

Wondering whether we need to have a subfolder for different scenarios. And this be in a "basic" folder.

As the characteristic of the "client hierarchy", some of them cannot co-exist in same main.tsp. E.g. client by namespace/interface cannot be in same file as client by @client/@operationGroup.

Yes. Those are separate scenarios and may not co-exist and should be placed in different folder.

[tadelesh]

@weidongxu-microsoft please hold this. i'm going to redesign all the client related thing in tcgc to consolidate all things related to clients, it may cause changes for decorator.

[weidongxu-microsoft]

@weidongxu-microsoft please hold this. i'm going to redesign all the client related thing in tcgc to consolidate all things related to clients, it may cause changes for decorator.

Sure.

Note that Face API already uses this decorator in their specs (and Java emitter also uses the .initialization in TCGC -- basically to put one ID path parameter to client parameter, in a subclient).
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/ai/Face/client.tsp#L125

I guess .NET also uses the TCGC info.

I am fine if you want to break some, though.