Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.

The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.

The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.

If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:

"result"=> ["service"]

If the "include-singletons" parameter was set to 'true' it would be:

"result"=> ["service=remote", "service=async"]

Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.

The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.

Note also that there is no simple element "service" in the above result. If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.

However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:

"result"=> ["datasource", "datasource=ExampleDS"]

A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".

Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:

"result"=> ["datasource=ExampleDS", "datasource"]