1. Override the XML provider as per my previous PR. This would allow the binding to provide its own XML in either the same, or slightly different formats. I know you're not keen on this...
   
2. As #1 - allow the binding to override the XML reader, but not allow changes to the XML format. I think this should be do-able in a similar way to #1.
   
3. Allow the binding to register a 'secondary' provider that can get the ConfigDescriptions from the XML file and change them.
   
4. Change the ConfigDescriptionRegistry class so that it appends all responses together rather than returning with the first response it gets.
   

1. Add a section to the XML to define a config description template. So we would have <config-description uri=""> followed by <config-description-template uri="">. The reader would then register both URIs but only the 'template' version actually has any description. This is effectively the same as your suggestion, but adding the extra element to allow the description to be incorporated into the same file.
   
2. Change the XML schema so that it can take a choice of <config-description>, <config-description-ref> or <config-description-template> (instead of the two choices currently defined). If the template version is provided, then it adds -template to the end of the uri and registers both URIs - as in #1.
   
3. We leave the elements alone, but in the <config-description> element, add a template="true" attribute - then the same as above.
   
4. Or add your option here
   

Then you can implement your own ConfigDescriptionProvider that provides "thing-type:zwave:thermostat" and internally does a ConfigDescriptionRegistry.getConfigDescription("thing-type:zwave:template-thermostat").

3. Wrt your second requirement, the dynamic options, I agreed with Dennis that this definitely qualifies for a new kind of service, something like a "ParameterOptionProvider" - this is something that we will probably need very often and which should not require implementing a full ConfigDescriptionProvider.

package org.eclipse.smarthome.config.core;

public interface ParameterOptionProvider {

    List<ParameterOption> getOptions(URI parameterURI, Locale locale);

    Set<URI> getSupportedURIs();
}

Maybe you're thinking of a possible use case for this, but I can't currently think of one

I'm not sure I see the need to request the options separate from the configuration / thingType either

    List<ParameterOption> getOptions(ThingUID uid, String parameterId, Locale locale);

To accomplish the same on things, we might have to add another method to the ParameterOptionProvider like:

If you create a new thing, all you have is its thing-type, so all meta-data must be available here - potentially also dynamically provided data.

I´m not sure if there is a need having dynamic parameter options for thing types only.

Which leaves us with Chris' problem that he would like to offer options specific to a certain device at a specific moment. The use case with the WLAN SSIDs is actually also such a case, so I guess sooner or later we need to address this.

// Handle the updates of any configuration
interface ConfigConsumer() {
    void handleConfigurationUpdate(Map<String, Object>);
}

// Handle dynamic configuration updates
interface ConfigDescriptionUpdate() {
    List<ParameterOption> getOptions(String parameterId, Locale locale);
}

Imho the problem is that we currently have config descriptions for thing type UIDs, but not for thing UIDs. So how could we possibly bridge this gap?

// Handle dynamic configuration updates
interface ConfigDescriptionUpdate() {
    List<ParameterOption> getOptions(String parameterId, Locale locale);
}

void registerUIDUpdata(UID, handler) {
 map.add(UID, handler);
}

ConfigDescription getConfigDescription(UID genericUID, URI uri, Locale locale) {
  // Get the config descriptions for this URI

  // Get the handler from the map for this UID

  // Call the handler to add the dynamic config changes
  for(parameter : allParameters) {
    parameter.options = handler.getOptions(parameter.Id, locale);
  }
}

I wonder if we shouldn't rather introduce config descriptions for things explicitly

Maybe I misunderstand, but isn't this then moving away from the generic config descriptions?

it could (I think?) be as simple as adding a getConfigDescription method in BaseThingHandler.

We would then need a new REST endpoint {thingUID}/config to get the config descriptions for the thing.

Moreover if you want to support dynamic option lists, but you don´t have a need to specify a specific thing CD, you are forced to do it

To provide dynamic options, you would only have to implement a ParameterOptionProvider and register it for the ThingUID CD URI (maybe this could even be done by the framework automatically, if the ThingHandler implements this interface).

Your option 3 does a similar thing, but now somehow implicitly introduces CD variants, by returning different results for the same URI on different requests. How would you map that to the REST API? /thing-types/<type>/config/<context>? Simply offering /things/<thing>/config looks much cleaner to me.

Kai, is the intention that this is implemented as a separate service? So the REST interface queries the CD registry, then queries the option service, merges them and supplies them to the user?

I have therefore added a GET thing/{thingUID}/config interface.

I do not see any reasons why it should not be possible to implement this as a generic service as neither the CDProviders nor the OptionProviders have any dependency to a specific type of entity.

• A generic REST interface, and have the conversion between CD URI and concrete URI performed in the UI (and the UI passes both the type, and the concrete URI).
  
• A generic implementation, but a specific REST interface that knows how to convert the CD URI and concrete URI for the specific data type (and the UI passes just the concrete URI)
  
• A generic implementation and generic REST, but somehow constraining the conversion from CD URI to concrete URI (and the UI passes just the concrete URI)
  

* A generic REST interface, and have the conversion between CD URI and concrete URI performed in the UI (and the UI passes both the type, and the concrete URI).
* A generic implementation, but a specific REST interface that knows how to convert the CD URI and concrete URI for the specific data type (and the UI passes just the concrete URI)
* A generic implementation and generic REST, but somehow constraining the conversion from CD URI to concrete URI (and the UI passes just the concrete URI)

No additional REST interface

A default implementation

Moreover we will introduce the interface "ConfigOptionProvider"

Yes you have to transform the URI, but this shouldn´t be a big deal.

What might irritate Chris though is the fact that the url /rest/config-descriptions does not exist yet

The way how and when config description are requested definitely needs to be changed.

Not 'irritate' but certainly confuse when everyone keeps talking about there being 'no additional REST interface' Smile

How do you propose to do this? You need to derive the type from the concrete URI which I don't think is possible at the moment without calling thing.getConfigURI (for things at least). Do we now assume that the type and concrete URI are directly derivable?

I think what I've implemented is what you want - it's just the REST API that isn't consistent with your thoughts. [...] It's only a few lines of code in the REST API that is thing specific - everything below that is generic

The structure of a Thing UID always contains the Thing Type UID. So we can grep it without making assumptions

But the REST Api don´t have to be thing specific, so I would really prefer to just give in the Thing UID and internally delegating it to the Thing Type CD, if no other ConfigDescription exists.

// Reset API for GET /thing/ThingUID/config
getThingConfig(thingURI) {
  thingTypeURI = thingRegistry.getThing(thingURI).getConfigURI();
  ConfigDescription cd = configRegistry.getConcreteConfigDescription(thingTypeURI, thingURI);
  return cd; // REST response
}

// Reset API for GET /config-description/UID
getGenericConfig(genericURI) {
  // Detect the type of the URI
  if(type of URI is thing) {
    typeURI = thingRegistry.getThing(genericURI).getConfigURI();
  }

  else if(type of URI is channel) {
    typeURI = channelRegistry.getChannel(genericURI).getConfigURI();
  }

  // repeated for other types
  ....

  ConfigDescription cd = configRegistry.getConcreteConfigDescription(typeURI, genericURI);
  return cd; // REST response
}

Do you want all this registered in the REST resource (ie the new /config-description), or do you want the REST resource and the ThingConfigDescriptionProvider split across multiple sources/packages?

Do you still want the ConfigOptionProvider type interface as discussed previously - if so, I'm not sure how this fits in as it sounds from your explanation above that there are no changes to the ConfigDescriptionRegistry (you say "nothing has to change there")

It requires the handler to be available. But I assume this is a fair assumption as this is likely anyhow in the same bundle as an registered OptionProvider would be.

We do not have a general solution,