Drop arguments property of Option Object

[patriksvensson]

I'm not 100% sure having an arguments property as part of an Option Object is what we want.

It makes the specification a little bit flexible for "weird" CLI:s, but I'm thinking it also makes it less readable, and more complex for implementors trying to make sense of an OpenCLI Description.

Consider the following OpenCLI Description:

{
    "$schema": "https://raw.githubusercontent.com/spectreconsole/open-cli/refs/heads/main/schema.json",
    "opencli": "0.1",
    "info": {
        "title": "Test",
        "version": "1.0"
    },
    "options": [
        {
            "name": "--foo",
            "arguments": [
                {
                    "name": "VALUE",
                    "arity": { 
                        "minimum": 1,
                        "maximum": 3                        
                    }
                }
            ]
        }
    ]
}

Which means that you can call this like this (depending on the CLI parsing capabilities of course)

$ ./myapp --foo FOO BAR
$ ./myapp --foo FOO --foo BAR

We could probably shorten this down to something like the example below, keeping almost the same capabilities, and keep things a bit more succinct. It's less flexible, but will probably work for 99.9% of all CLIs.

{
    "$schema": "https://raw.githubusercontent.com/spectreconsole/open-cli/refs/heads/main/schema.json",
    "opencli": "0.1",
    "info": {
        "title": "Test",
        "version": "1.0"
    },
    "options": [
        {
            "name": "--foo",
            "valueName": "VALUE",
            "arity": { 
                "minimum": 1,
                "maximum": 3                        
            }
        }
    ]
}

Does anyone have thoughts or opinions?

[ap0llo]

I guess it comes down to a tradeoff between making the spec easy to read and expressing all possible (maybe weird) CLIs.

I think just having a value name and arity in the option would definitely be easier to understand and interpret, but it will loose expressiveness.

In your example above, the difference between $ ./myapp --foo FOO BAR and $ ./myapp --foo FOO --foo BAR could not be expressed in an open cli spec.