FHIR Chat · cnl-0 on OperationDefinition · conformance

Stream: conformance

Topic: cnl-0 on OperationDefinition


view this post on Zulip Josh Mandel (Apr 12 2022 at 02:15):

https://build.fhir.org/operationdefinition.html#invs includes:

cnl-0 Warning (base) Name should be usable as an identifier for the module by machine processing applications such as code generation name.matches('A-Z{0,254}')

... but we violate this in 100% of in our core (including normative) OperationDefinitions (see https://build.fhir.org/operationdefinition.html#defined), which all start with lower-case letters and frequently include hyphens. Is there really justification for issuing warnings based on cnl-0 for OperationDefinition.name?

view this post on Zulip Lloyd McKenzie (Apr 12 2022 at 02:40):

The .name values should all be fixed. It's unlikely anyone is using them, but if they want to, they won't be able to because they're not valid class names.

view this post on Zulip Grahame Grieve (Apr 12 2022 at 02:52):

agree that they should be fixed

view this post on Zulip Grahame Grieve (Apr 12 2022 at 03:07):

are fixed now.

view this post on Zulip Josh Mandel (Apr 12 2022 at 03:09):

(For the record, I got confused about name vs code when I posted this message -- like most people I don't actually care much about name, but I'm all for reducing unnecessary warnings ;-). The thing I really care about is that these operations are invoked via codes like $find-matches or whatever. Which of course is orthogonal to the names, and is working just fine.)

view this post on Zulip Grahame Grieve (Apr 12 2022 at 03:10):

indeed code is what matters

view this post on Zulip Brian Postlethwaite (Apr 12 2022 at 03:35):

The name property is what I'm code generating TypeScript extension helper methods with - and had to do some local cleanups for SDC...


Last updated: Apr 12 2022 at 19:14 UTC