sh:codeIdentifier is restrictive.

[afs]

The illustration of sh:codeIdentifier is for GraphQL but either the property name should reflect that or the range should be be loosened.

sh:codeIdentifier is an xsd:string matching ^[a-zA-Z_][a-zA-Z0-9_]*$.

• It's ASCII
• It is very specific e.g. no : or - for identifiers other than GraphQL
• "code" is ambiguous - a "code" can be an identifier for an instance of this shape (classification use case)

[HolgerKnublauch]

Yes, this was intentional. My thought was that these codeIdentifiers should be in a format that can be correctly interpreted as a variable/field name is basically any programming language that exists right now. So it's a bit like the common intersection. (Does anyone know a language where these rules are not accepted?)

If we relax this, for example by allowing - then the identifiers could be used only in some languages but not others, defeating the purpose of the property.

Which language do you have in mind where you would need non-ASCII or : or - ?

[afs]

Which language do you have in mind where you would need non-ASCII or : or - ?

Most nowadays, natural language names for variables etc are the norm.

var été = true

GraphQL ID is a string -- "GraphQL is agnostic to ID format," -- so whatever the underlying identifier space

[HolgerKnublauch]

GraphQL names are defined here and only support ASCII letters: https://spec.graphql.org/September2025/#sec-Names

I agree that almost all modern programming languages do support Unicode, but they don't support : or - that you originally requested. And older programming languages are still ASCII only.

In languages like SQL (e.g. column names), arbitrary names are permitted but need to be wrapped with "..."

I still think that going with the lowest common denominator is best here. We can reduce that rule to a SHOULD recommendation, I wouldn't block that. But definitely not : or - People already have that freedom in URIs and qnames, so the value of codeIdentifier would go away if we make it too flexible.