Feedback on 2.0 (continued -- CODE SPRINT JAN 2026)

[jerstlouis]

• 9.3.2. Data classes dataClasses parameter -- can we please change this to property as well (and anywhere parameter is used for a meaning other than query or path parameter)
• 9.3.3 69 C: typo in coverages: ogc-api-covreages (remove the e)
• There are conflicting spellings in the informative text s. the requirement -- should it be plural with uppercase API? Would make sense to me that it is plural dataAccessAPIs (it's singular and Api in the normative clauses)
• The example has messed up metanorma rendering
• The messed up example has typos paramater and accomondate
• Req. 70 schema parameter -- schema property; B: inpuit value typo
• Req. 72 Value passing B and D shall is not in uppercase. Use property rather than parameter here again for valuePassing
• Req. 72 -- it took me a while to understsand what is meant by the 4 clauses of this requirement... Perhaps it would be good to start with something like:

If a server implementation only supports input values passed either by reference or by value, the valuePassing property of the process description SHALL list the supported input passing mechanism.

It's also very odd to call this property valuePassing with "byValue" being one of the option. How about inputPassing instead?

• 9.3.7 A: correspoding typo missing n
• executionUnitRequrements parameter -> property
• executionUnitRequrements -- it's not clear what remote-access and staging are -- are these sub-properties of the executionUnitRequrements property, which is a top-level property of the process description? also remote-access should probably be camelCase rather than kebab-case.
• 9.3.7 -- it's not clear to me whether this pertains to Part 1 or not? Shouldn't this rather be in Part 2? Does it have any implications on how a client submits an execution request? Or is it more about how the Part2-capable server handles execution units which expect to handle networking etc.?
• 9.4.2. Data classes parameter and 9.4.3. Data access APIs have some TBD (but also See Also)
• Req. 80 /req/oas/definition -- This seems to have kept some Features API-specific language about Feature Collections that should be adapted to processes or generalized
• Req. 89, it's confusing to talk about "the parameter" (type query parameter in this case, which is a reference to Req 88) without context because it is in a completely different requirement. In general, I'm not a fan of splitting request/response into different requirements because I feel it makes the documents longer than they need to be (I prefer to use different A, B parts instead), but if the requirement is split, there should be enough context for a reader arriving directly at any of the requirements and make sense of it (e.g., being pointed there due to an ETS failure)
• datetime query parameter -- that should probably talk about bounded/half-bounded intervals rather than open/closed as was clarified before in OGC API - Features etc.

[fmigneault]

should it be plural with uppercase API? Would make sense to me that it is plural dataAccessAPIs

How about using dataAccessMechanisms?
That is the wording in common and in textual descriptions. Would be easier to interpret what it represents. It would also avoid the "API" ambiguity for static storage data location that is somewhat odd, though could technically be used.

It's also very odd to call this property valuePassing with "byValue"

Just for traceability, attributePassing was proposed during the Code Sprint. Seems like a good option.

executionUnitRequrements -- it's not clear what remote-access and staging are -- are these sub-properties of the executionUnitRequrements property, which is a top-level property of the process description? also remote-access should probably be camelCase rather than kebab-case.

They are values in an array, just like the jobControlOptions and dataAccessApis. They respect the kebab-case for that reason.

[jerstlouis]

@fmigneault

How about using dataAccessMechanisms

I'm happy with that.

Just for traceability, attributePassing was proposed during the Code Sprint

Actually it was argumentPassing that we mentionned (we were doing the parallel with C function calls).
My original suggestion above was inputPassing, because we are specifically talking about the inputs to the processes are being passed. I just don't like valuePassing because it sounds quite odd to say passing a value by value.

They are values in an array, just like the jobControlOptions and dataAccessApis. They respect the kebab-case for that reason.

Hmm OK I'm not sure that was a conscious decision to use kebab-case there for enumeration values, because it causes the same additional difficulties mapping these identifiers to C-like languages (as discussed here).

Regarding the typo in executionUnitRequrements (missing i) it is present in Requirement 73 A.

[fmigneault]

I prefer to stay consistent in the naming convention, which dates back pre-v1 using [a]sync-execute.

I don't see the difficulty any differently than resolving eg. ?filter-lang=cql2-text. Every language will have to do some particular handling for different cases. You could do a #define or a regular enum with char/int converter function for C. It really shouldn't be a concern for the API definition.

[jerstlouis]

@fmigneault It's different for object notation vs. query parameters, because it is common to automatically map a struct/class definition (including all its members/properties) to a JSON type. Yes there are always workaround, but the general recommendation/suggestion from Common is to avoid kebab-case in JSON.

[fmigneault]

You would have to do the same operations for the cql2-text value if provided in the JSON body and wanted to define an enum of supported filtering languages to validate against in the code. I think kebab is just one case amongst many others that cannot be avoided when porting on the implementation side. Even if camel/snake case was used, that might not align with other languages (eg: PEP8 linters in Python that yells at you when using camel).

I am curious where you find that Common indicates this recommendation? I could find a Kebab-Case reference, and Common Recommendation 13 B promoting it. Inversely, didn't find any mention of "camel", "pascal" or "snake" case anywhere, or anything hinting at avoiding kebab case for any form of enum value definition.

It seems Common says "can be anything" at best, and does not restrict nor recommend any naming method as to allow other standards to use any variant. There seem to be really not much, if any, recommendation for enum values.

[jerstlouis]

@fmigneault

I am curious where you find that Common indicates this recommendation?

It is not a recommendation from a standard document. Just the best practice that we agreed upon in the issue there.

The recommendation promoting kebab-case is specifically for query parameters.

PEP8 linters in Python that yells at you when using camel

At least that results in a linter style warning rather than a syntax error in C-like languages :)

You would have to do the same operations for the cql2-text value if provided in the JSON body and wanted to define an enum of supported filtering languages to validate against in the code.

And you could use cql2Text for that enum value in a JSON schema definition. That's still a completely different thing to the query parameter itself.

I guess the distinction with enum values is that it is not the data membernaming issue, but only on an issue if you map these to actual C-like enumeration values (as opposed to leaving it a string, as enum values are in JSON).

[fmigneault]

They are still only about property names. Nothing about values. The fact that it is an old, unresolved, and not implemented issue doesn't really help, though I don't disagree about the naming conventions proposed for the names there, as they help distinguish them apart.

Here, the executionUnitRequrements: ["remote-access"] that started this whole discussion is about a value. The cql2-text I provided is the same thing, either as query or embedded within the JSON as collection input for example.

Therefore, if you want to control (as same for executionUnitRequrements/remote-access, or for C code):

class FilterLanguage(Enum):
    CQL2_TEXT = "cql2-text"
    CQL2_JSON = "cql2-json"

if response.query.get("filter-lang") == FilterLanguage.CQL2_TEXT: ...

It is the same thing regardless. The enum reference in the code has to deal with the _/- value and all workaround shenanigans that come with it.

My stance in this case is that async-execute, etc. was used for jobControlOptions, so the executionUnitRequrements should follow the same kebab convention for its values.

[jerstlouis]

It is the same thing regardless.

Not quite, because you often let the JSON reader automatically convert an entire document into an object, whereas a query parameter you often have manual code that does the mapping (as per your example). That was/is my argument for camelCase throughout JSON objects anyhow.

My stance in this case is that async-execute, etc. was used for jobControlOptions, so the executionUnitRequrements should follow the same kebab convention for its values.

My stance is that async-execute should have been asyncExecute and we should not propagate the mistake further and make it "remoteAccess" :)