A "node" is an element that looks like this:
{
"type": "root|literal|argument",
"parser": "", // only applicable if type is argument
"properties": {}, // only applicable if type is argument, defaults to empty object
"executable": true, // default if not specified is false, meaning it isn't a runnable command by itself
"children": {}, // default if not specified is {}, meaning no children
"redirect": [] // default if not specified is null, meaning no redirect
}
A redirect is a path to another node in the tree. ["foo", "bar", "baz"] means "find the child named foo of the root, then the child of that named bar, then the child of that named baz".
Every element of children is another node, which itself may have more children.
A literal type means "I expect the literal name of this node", and has no properties.
An argument type means it's dynamically parsed, using parser (and any optional properties)
This looks pretty nice already. It's good to have an official in depth description of command syntax.
I'm kind of missing permissions, tho. Say you want to write a command parser for functions. Commands like
/banare probably not going to be allowed in functions. It would be nice if we could filter these out.It would also be nice to have a list of valid parsers, a description, and valid properties for the specific parser, including default values.
The description might be anything from a small sentence to json tree similar to this on. Especially for
minecraft:entity, it might be good to describe the selector arguments similarly, tho.Also, I know that for
minecraft:particleit is mostly literals of valid particle ids, but some ids might have additional arguments as it looks like. E.g. blockdust expects a block:minecraft:blockdust minecraft:stone, without a block id, the blockdust particle isn't actually valid. I don't know if there are more special cases where similar things apply, but that's also a reason I would like a better description for the parsers.