With the 'Parametered' class there are more and more cases where the configuration file does not know what data is stored, it only knows that some data might have been stored. This led to a function that simply loads each attribute into a parameter.

Unfortunately there is a problem with handling this naive. When loading the parameters some of them are duplicated. Take the following device description

<device PLMProtocol="I2" address="0f979800" group="Downstairs" name="KepadLincR8 - Downstairs main light"/>

The address, group and name attributes are used natively by the 'Device' object, "PLMProtocol" is a 'Parametered' parameter that is used the 'PLMProtocol' object. When the device is read from the config parser, the 'Parametered' object holds all of the attributes, even though the the majority of them are stored elsewhere (and probably more efficiently). This duplication needs to be eliminated. This may also cause problems when writing the data back out to the configuration file when two parameters with the same name are added to the node.

As the 'Parametered' functionality gets more use, there could be issues with two users naming a parameter the same thing. While at the moment this does not happen, there is the possibility. To avoid this, Parametered will get the concept of namespaces. Each parameter will be a member of a namespace. For example from above, instead of "PLMProtocol" the parameter may be "Protocol" in the "PLM" namespace. The parameter will be stored in the map at "PLM.Protocol" and will be written to the configuration file in the same way. With the period separating the namespace and parameter names, it will be possible to determine the difference between a 'Parametered' parameter and a native attribute, fixing the issues of the previous paragraph.