The Temperature class can be used in MeasureDataPublication to measure airTemperature, dewPointTemperature, maximumTemperature and minimumTemperature.
Currently, the data dictionary can be created out of the XMI-input file. All elements included in this file will be part of the dictionary (anyway, there is a possibility to [de]select packages). But there is no correspondence between the dictionary and the profile selection you might perform on this input file.
The enumeration "MeasuredOrDerivedDataTypeEnum" has - among others - two literals:
But there are no classes to represent these type of data like it is for all other literals (i.e. there is no component "RadiationInformation" and no component "PressureInformation").
new countries are not in the list.
Constraints like "One of these three clases must be used." are written in form of comments in the UML model right now.
There is no possibility to tranfer these constriction into the schema (and to check this constriction within an resulting XML).
This would be nice to have, probably with using something like OCL.
To avoid client problems receiving data from providers using both extensions with the same name, the names of extensions should be managed by the Helpdesk. Providers can request an extensionname for their extension. It is requested to request a name on the website and that there is a list on the site with the assigned names.
Everything in the model that is based legal documents like laws, acts, regulations etc. should be recognisable as such in order to recognise the impact of modifying things.
Apart from that all legal related information should be in the model using own datatypes etc to avoid impact from modifications in the other parts of the model.
User experience is that the complexity of defining profiles in a two separate tools. The problem is that on UML level a profile is not visible and UML, which is extremely usefull in documentation.
It would be good to have an integrated approach that supports the requirement to deal with profiles in UML as well.
The reference from one situation to another is now only feasible by refering to a version of a versioned identifiable of another situation. This is not nice as it generates a lot of traffic which does add unnecesary complexity
The definition:
"One or more physically separate locations. Multiple locations may be related, as in an itinerary (or route), or may be unrelated. It is not for identifying the same physical location using different referencing systems."
The confusing thing is stating that a group can be 1. That is strange.
The clause "It is not for identifying the same location using different referencing systems" is wrong. It is the only way to do it within the group of locations.