Be explicit about support for complex YAML keys

[perrygreenfield]

The YAML 1.1 spec permits object keys to themselves be objects or arrays, which isn't well supported by Python (since dicts and lists are not hashable). A more serious issue is that complex keys are not at all covered by JSON Schema, since JSON only supports string keys. Consider declaring in the ASDF Standard that object or array keys are not permitted.

Restricting our tree to a subset of YAML would also offer the benefit of a simplified implementation if we ever decide to write our own fast YAML parser.

One option is to require complex keys be encoded as strings, perhaps with some specification of what is legal. Again, this would requires some thought. We would like to stay away from anything goes for keys.

[embray]

Did we ever explicitly say this was supported, or was it just not explicitly unsupported before? I didn't even know (or forgot) that YAML itself supported this.

I have a lot of experience with the guts of PyYAML now and could also probably provide a modified parser that explicitly disallows this.

[jdavies-st]

No, we haven't been explicit, so I think the idea is to be explicit here one way or another. And there's good reason to go for the simple approach that is supported by the existing yaml libraries and jsonschema.

This was initially pointed out in asdf-format/asdf#642 where tuple keys are not supported by any of the python YAML libraries in the way we need.

I think we want to go for simplicity here.

[embray]

I think we want to go for simplicity here.

Agreed. I suppose as a middle ground it could still be supported in custom user data, but it definitely shouldn't be allowed by anything which is checked by a schema. And since we want to encourage the use of schemas anyways it seems simplest to just make it an explicit limitation. There are other ways tuple-like keys could be used with a string formatting schema.