Namespace & Names Case Sensitive

[calvinrp]

From my read of the Component Model spec and the validation code, namespaces just need to validate as the KebabStr (see validation code).

So my-NAME, MY-NAME, MY-name and my-name are all valid KebabStr. I assume we would want to match case insensitive to prevent confusion.

Should namespaces be required to be lowercased to pass validation? Or just match case-insensitive? If not lowercased, do we want to keep the original casing for presentation purposes?

On a similar note, how do we want to handle casing in package names with respect to the registry and LogIds? It is possible to hash as lowercase. Currently, PackageId (soon to be PackageName) is case sensitive and produces different LogIds depending on the case.

[lukewagner]

My impression is that we should be case sensitive, but disallow two package names that differ only by case. Thus, we're never throwing away case (which is meaningful, since it renders into source code identifiers differently), just preventing ambiguities or possibly, depending on the casing scheme, collisions. (Maybe the component model should do likewise in its uniqueness...)

[calvinrp]

I would rather we reject namespace names which are mixed case or uppercase so that we don't have log data with mixed upper/lower and propagate an error to users that the namespace they chose is not legal.

We could allow case sensitive names and namespaces for presentation and code gen. But generate the LogId in a case insensitive way (all lowercase).

[lann]

I guess if namespaces definition is generally considered to be the responsibility of a registry then lowercase-only is really just policy.

[calvinrp]

Lower-only namespaces seems like a pretty reasonable starting point but I'm a bit wary of diverging from WIT...

Yeah, I'm concerned about that. Think we need to support what is valid in the component.

[esoterra]

@lukewagner are we expecting namespace names to be full kebab names? I hadn't seen any examples of multi-part namespace before and assumed they were just all-lower one part stubs?

If they're full kebab names, then I definitely agree we should match WIT on casing and just avoid letting people use two case-insensitively equal names in a given context.

[lukewagner]

At the moment, namespaces are labels which are full kebab names. I didn't put a ton of thought into whether namespaces really needed this; it's just that label tends to be our most basic string token used in all the places.

[calvinrp]

After a lengthy discussion with @esoterra and @lann, we came to agreement that we need to hash (LogIds) and match names in a case sensitive way, but we should enforce uniqueness on both namespaces and package names in a case insensitive way.

Since changing the case of a name affects the generated bindgen code, it can change behavior.

This does open up a possible typo squatting situation if a registry does not correctly enforce case insensitive uniqueness. The federating registry that imports another registry's namespace should check that this uniqueness is enforced.

Registries may choose to adopt a more restrictive policy that only allows lowercase names, for instance.

[oovm]

Hi, @calvinrp ,Who does Registries refer to in this context?

For example, if I am the owner of the namespace, do I have permission to require additional checks for the style of the uploaded package? The style must be met for successful publishing.

For example, some languages (such as C#) may like upper camel case, and some prefer all lowercase letters.

[calvinrp]

@oovm Registries refers to any Warg registry instance. During package publish, a registry reject the package for any reason that it chooses. Having pluggable Wasm components that can enforce custom policies is something that we are working towards.

The context of this thread isn't for a custom policy but rather something to enforce in the Wasm component spec and at the registry level. We landed on having package namespaces and names be all lowercase. When you generate bindings, wit-bindgen or such, you can convert the identifiers to whatever convention makes sense in the target language.

Related:
WebAssembly/component-model#338
PR merged #265