Add a reserved namespaces deny list to restrict trait-codegen from using smithy specific namespaces.

[yasmewad]

Background

• What do these changes do?
Adds validation to prevent trait code generation on smithy keyword itself or reserved Smithy namespaces ( smithy.api, smithy.waiters, smithy.test) and their sub-namespaces but we still want to allow namespaces like smithy.foo or smithy.rules .

This change adds a RESERVED_NAMESPACES set to act as a deny list for future extensibility.

For instance:

smithy -> not allowed
smithy.api , smithy.waiters , and smithy.test -> not allowed
smithy.foo, smithyfoo.bar, -> allowed

• Why are they important?
Prevents namespace conflicts with core Smithy functionality and protects framework integrity by blocking user code generation on reserved namespaces.

Testing

• How did you test these changes?
Added comprehensive unit tests covering reserved namespace validation, case-insensitive matching, edge cases, and legitimate namespace acceptance.

Links

• No related issues

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sugmanue]

You are missing some, the full list as of now is:

smithy.api
smithy.framework
smithy.mqtt
smithy.openapi
smithy.protocols
smithy.rules
smithy.test
smithy.waiters

[yasmewad]

Ack. Are these from just the github search? Or some other mechanism you used?

[sugmanue]

A shell script:

find . -name \*.smithy | xargs egrep '^namespace ' | grep ' smithy.' | cut -d: -f2  | grep -v ' test' | grep -v example | sort | uniq | cut -d ' ' -f2 | cut -d '.' -f1,2 | uniq

[yasmewad]

Nice Thanks!

[yasmewad]

I have updated the namespace list.

[kstich]

This needs several other sub-namespaces: .mqtt, .openapi, .protocols, .rules, .framework

[yasmewad]

Will update.

[yasmewad]

I have updated the namespace list.

[sugmanue]

Let's remove this conversion, namespaces are case sensitive.

[sugmanue]

Confirmed offline that this needs to be case sensitive.

[yasmewad]

Yeah, while namespaces are case-sensitive, the rationale of this was anyone should be forbidden from creating a trait with SMITHY or SMITHY.API or other versions of it as it conflicts with our reserved namespaces.

I am leaning towards blocking those case-insensitively. @mtdowling and I discussed, the reasoning for case-insensitive checking is that shapes are case-insensitive.

FWIW, for future record putting this here from our docs :

While shape ID references within the semantic model are case-sensitive, no two shapes in the semantic model can have the same case-insensitive shape ID. This restriction makes it easier to use Smithy models for code generation in programming languages that do not support case-sensitive identifiers or that perform some kind of normalization on generated identifiers (for example, a Python code generator might convert all member names to lower snake case). To illustrate, com.Foo#baz and com.foo#BAZ are not allowed in the same semantic model. This restriction also extends to member names: com.foo#Baz$bar and com.foo#Baz$BAR are in conflict.