Every SdkType should have a name and namespace

[ArcturusZhang]

The downstream SDK might not use this information, but semantically speaking, every type should have a name and namespace.
For example, the name of string type could just be string, and its namespace could be something like TypeSpec.Internal or TypeSpec.Foundations whatever defined in the typespec type system.

[tadelesh]

@iscai-msft this namespace is not client namespace, it is the typespec original namespace which will be used to identify the source of the model to do model replacement. for e.g., Azure.Core.ResponseError will not be generated and replaced with a .net core model. do you think we could add a tspNamespace for all tcgc types?

[iscai-msft]

I still don't get why it's needed, since we filter out core models. Can you give more of an example of how the namespaces would be different and what the usage would be? Thanks!

In terms of name, what is the point of naming a scalar type?

[ArcturusZhang]

I still don't get why it's needed, since we filter out core models. Can you give more of an example of how the namespaces would be different and what the usage would be? Thanks!

In terms of name, what is the point of naming a scalar type?

For example, when some one writes this:

model Foo is TrackedResource<FooProperties>{
	...ManagedIdentityProperty;
}

to get a tracked resource model with an identity property.

When we get the model from TCGC, we need to know the type name and namespace ManagedServiceIdentity because we are not going to generate this model in every library, we want to generate this model using the type from our Azure.Core or Azure.ResourceManager (the core library of ARM), therefore we need to know where this model comes from, is this model a model defined in the tsp of the service, or it comes from a core template like azure.core or azure.resourcemanager.
The namespace is important here because we need a way to identify such cases.

To summary, we want the namespace on models and enums (and potentially every other types) because we want to identify which typespec file these type come from so that in the generator of SDKs, we could know if a type should be generated into files as part of the library we are currently generating, or this type should be generated as an existing type from a core library (in this case, no file will be generated for it)

For the requirement on name, it is not something we would use, just for completeness of the system, because logically, every type should have a name, for example, the name of built-in type string is just string, and this is how we call it.

[ArcturusZhang]

Another example of "we need namespace" for types is this: https://azure.github.io/typespec-azure/docs/libraries/azure-core/reference/data-types#Azure.Core.EmbeddingVector
We only know this is an array, we get an instance of SdkArrayType. But we do not know how this array is defined - therefore we need to know the name and namespace, for instance, { name: EmbeddingVector, namespace: Azure.Core } so that we know this array is constructed by the embedding vector, and we could generate a different type from the usual array.

[qiaozha]

In RLC, we have similar logic to trace the namespace all the way to the top to determine if this type is from Azure.Core.