On Tue, May 10, 2022 at 10:52:34AM +0100, Daniel P. Berrangé wrote: > On Mon, May 02, 2022 at 10:01:41AM -0400, Andrea Bolognani wrote: > > Revised proposal for the annotation: > > > > ns:word-WORD-WoRD-123Word > > Ugly, but we should only need this in the fairly niche scenarios, > so not too pain ful to add a handful of these: > > Essentially if have the schema use CamelCase with UPPERCASE > acronyms, and declare two rules: > > 1. Split on every boundary from lower to upper > 2. Acronym detection if there's a sequence of 3 uppercase > letters, then split before the last uppercase.
That should cover most of the type names, but we're still going to need to help the parser out when it comes to detecting acronyms in other contexts, such as all instances of the word "VNC" below: { 'enum': 'DisplayProtocol', 'data': [ 'vnc', ... ] } { 'command': 'query-vnc-servers', ... } { 'event': 'VNC_DISCONNECTED', ... } > QAuthZListPolicy > > Rule 1: QAuth + ZList + Policy > Rule 2: QAuth + ZList + Policy > > so only the last case needs ns:QAuthZ-List-Policy annotation, whcih > doesn't feel like a big burden Note that in my proposal the ns: part would be used exactly for cases like this one to separate the namespace part which, as you said in your other reply, needs to be preserved when generating C code but can be safely dropped when targeting a language that has actual namespace support. So the annotation would look like Q:AuthZ-List-Policy in this specific case. The ns: part would be optional, as a namespace is not embedded in most of the names. It's also interesting to see how "AuthZ" is capitalized in various Go modules that implement the concept: https://pkg.go.dev/search?limit=50&m=symbol&q=authz Most use "Authz" rather than "AuthZ". If we get to the point where the only bit of weirdness is how we spell this specific word, I think I'll be able to live with it :) -- Andrea Bolognani / Red Hat / Virtualization