DSL type and relation casing best practice

[Raid55]

I have another quick question around type naming best practices.
Would naming types in pascal casing be ok?
I saw that kebab casing was used (assets-category) and wanted to make sure that there isn't a technical reason or docs i missed as to why a specific naming standard needs to be adopted for naming types (or relations for that matter).
Example:

type User

type Workspace
  relation member: [User]
  relation guest: [User]

type Document
  relation workspace: [Workspace]
  relation owner: [User]
  relation fullAccess: [User] or owner
  relation write: [User] or fullAccess
  relation read: [User] or write
  relation canDelete: fullAccess and member from workspace # this would prevent a non-member from delete
  relation canShare: fullAccess and member from workspace 

type AssetsCategory

etc...

For context, the reason why I want to use pascal and camel casing is because the types declared are already models in our graphql schema and for this POC I want to keep developer experience to avoid engineers having to fit a new way of naming types they are already familiar with.

[rhamzeh]

Hi @Raid55

From the DSL perspective, it does not matter.

We have not established best practices around this, and it depends on how you prefer it.

One advantage of using snake_case/TitleCase/camelCase over kebab-case is that people can select that quickly whether through mouse or keyboard when needing to (e.g. to copy paste or reference it)