Ideas could be taken from Commandly #63

@patriksvensson @devin-fisher

I'm not sure if tagging me is warranted. I've only contributed a small typo fix. But we do have something in common. I'm have also been build a cmd builder much like you Commandly. Although you seem to be ahead and mine is intended to be a TUI (not a GUI). I've been using this projects beta spec for my app and I have been keep some notes about the spec as I use it.

Let comment on you list:

• IDs for options, arguments, etc. -- I have not found a need for this in my app yet. I'm curious what you would normally put for an id, like UUID?
• isDefault property on commands. -- I'd like to know more about what you mean by this? I'm unclear on it.
• IsRepeatable property on options. -- this one is interesting. I've generally assumed that options are repeatable but more explicit might be better here. The Argument Object has an arity field that might server this purpose if added to options
• Data type like string, boolean, number, etc. -- This could be useful for error checking but it is bag of warms in that their are many different ways to specify data types and in the end all, terminal only except characters. I'd be interested if their is a useful line that we could draw that is not too permissive to be un-useful or too restrictive to make some commands indescribable.
• Short flag, long flag aliases -- In my use, I've not found this restrictive, but my app only uses the canonical for which I expect to be in the name field and don't really use the aliases (it is opinionated in that way by design).
• Key value separator for options. Some tools require spaces, = , colon, etc -- this is very much needed and in my notes. Although I've not run in to this issue yet it is only because I have not gotten to rendering the build command to a valid text string for a terminal. The Conventions Object object seem like a good place to this unless we think different option in the same command have different separators
• Position property for Arguments. -- I'd like to hear more about this. I've been assuming that the postion in the array was it postion in the command. So like for mv you would specify first the an Argument Object that is the source file with an arity that is 1-* arguments and then an Argument Object that is the dest file with an arity that is 1. What usecases can the current spec describe?
• Dependencies of an argument, option on other options. -- I'd image there be dragons here. What commands and use-case have you encountered that leads you to want this? I'll love to hear about it.
• Validations for input data on an option or argument. -- I think this could be very useful but I might be inclined to feel that this is an unnecessary complication on a initial version of the spec. Maybe?
• Default Values -- I want this too. The initial command that I'm building my app around is kubectl and they have the default value (the value taken if the option is not specified) in the usage documentation. I would like to be able to document this in the spec. I think it is important for those that are trying to build commands.

You have covered most of my notes except:

• It would be useful to be able to specify that common use of -- which often detones the end of the parsing by the given command and everything after it is given to so other command. For example kubectl exec -it transform-nifi-0 -c metrics -n dev -- /bin/sh -c "cat /etc/hosts" I'm not totally sure what a good way to do this in the opencli spec but it is commonly used.
• Some of the default values in the documentation are not reflected in the json schema. I was going to open a PR for that at some point, easy fix.

@divyeshio I hope this is not too long coming. Having uses even in this alpha or bata stage is very useful. I was not sure if anyone was using it when I adopted it but I did not find anything else I did not want to create my own.

@patriksvensson Please let me know if there are better places to discuss this.