Fam Zheng <f...@redhat.com> writes: > On Mon, 05/05 21:09, Eric Blake wrote: >> On 05/05/2014 07:30 PM, Fam Zheng wrote: >> >> >> NAME: { 'type': TYPE, 'default': DEFAULT } >> >> >> >> where >> >> >> >> NAME: { 'type': TYPE } >> >> >> >> can be abbreviated to >> >> >> >> NAME: TYPE >> >> > >> > In data definition, we allow inline sub-structure: >> > >> > { 'type': 'VersionInfo', >> > 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'}, >> > 'package': 'str'} } >> > >> > If we allow properties as a dict, we need to disambiguate properly from the >> > above case. Proposing: >> > >> > MAGIC: { 'name': NAME, 'type: TYPE, 'default': DEFAULT } >> >> Oh, good catch. The alternative is to drop all instances of inline >> sub-structs. Searching for 'data.*{.*{', I found only VersionInfo and >> PciBridgeInfo; I then did a full manual search of qapi-schema.json and >> only found the additional instance of PciDeviceInfo where the sub-struct >> is not on the same line as the initial { of the 'data'. Just getting >> rid of inlined sub-structs may be quite feasible. > > Sounds good. > >> >> On a related vein, there are a number of types that aren't merely a >> string name. For example: >> >> { 'command': 'migrate-set-capabilities', >> 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } >> >> and similar, where we have an array type rather than a raw string type >> name. But at least with that, NAME: { 'type': [ 'array' ] } is still a >> reasonable parse. >> >> The problem with MAGIC:{'name'...} is that you need to express more than >> one parameter, but as a dict, you can't reuse the same MAGIC more than >> once. That is: >> >> 'data': { MAGIC : { 'name': 'qemu', 'type': { 'major'...} }, >> MAGIC : { 'name': 'package', 'type', 'str' } } } > > Right. > > Not necessarily better than dropping inline structure, just another idea: > > 'data' { '@arg_with_properties': { 'type': 'str' }, > '*simple_optional': 'str', > '@optional_full': { 'type': 'int', 'default': 1 }, > 'the_most_common_form': 'bool', > 'inline_structure': { 'major': ...} } > > Where '@' is a prefix for property dictionary similar to, while exclusive > with, > optional mark '*'.
If we decide to keep the '*' sigil, we can add more. Two similar violations of the "no syntax beyond JSON" design rule aren't really worse than one. That said, I dislike all sigils equally :) [...]