Using a type to define allowed additional properties?


#1

In RAML 1.0, we can use regular expressions to constrain the property names for addition properties. I’d like to be able to re-use an expression in multiple places, without having to repeat the expression.

Using a string-based type as a constraint on the property names would be especially nice. Perhaps something like this:

types:

  node_name:
    type: string
    pattern: "[a-z0-9]([-a-z0-9]*[a-z0-9])?"
    minLength: 1

  system_info_group:
    type: object
    additionalProperties: true
    properties:
      *node_name: system_info

One requirement, of course, is the need to identify some indicator that YAML doesn’t already overload in strange ways.


#2

MH I think YAML might be indeed a problem as it uses * as an indicator for anchors. I understand that you want to reuse certain patterns, but that might be a bit more difficult for keys.


#3

@fdrake, I am completely agree with you on this suggestion. During my latest experiments with amazon web apis I found that their internal API description language has a concept of map type, which describes exactly this situation and allows to specity distinct types for keys and values. As for me it looks like pretty often use case, but as @christian_vogel correctly mentioned * is already busy as indicator for anchors.

Regards,
Pavel


#4

I was only using * as an example marker; someone with more YAML knowledge than I might be able to find a character that doesn’t already have significance.

Another possibility might be to have additional facets that could be applied to a type in lieu of the properties facet:

types:
  system_info_group:
    type: object
    propertyNameType: node_name
    propertyValueType: system_info

This would have the effect that only one such combination could be provided. Combining with a properties facet could be tolerated so long as keys accepted by propertyNameType don’t overlap with properties accepted by regular expression keys in the properties facet. (We’d still want specific keys from properties to win out over propertyNameType.)

A wilder hair would be to accept something that’s not sane as a regular expression, but that might be more difficult for implementers:

types:
  system_info_group:
    type: object
    properties:
      /*node_name/:  system_info

(Keeping in mind that a leading * in an RE isn’t sane.)