Hey Christoph,
I also have a few comments. I initially thought this could have potential. But, I think it introduces too much complexity.
1) We already sort of have a BaseSensorDataType. The SensorDataEntry provides absolute mandatory fields like timestamp, tool, etc.
2) I'm not sure what this Hierarchy would accomplish. Even a LatexFileMetric SDT and JavaFileMetric SDT would have to have a file attribute. And we could place all the Latex and Java specific things in the PropertyList (see eSDT). The bottom line is that after getting the data from the SensorDataEntry there is _no_ difference in how the semantics of the SDT are organized.
3) The fancy thing that you've mentioned is pretty cool. That is why I thought this has potential. Here's an example why this would be cool. Currently, if we wanted to run an analysis on strictly FileMetric data from Latex, then we would have to search through all FileMetric instances. In other words, the indexing of Sensor Data is only limited to the SDT (FileMetric, UnitTest, etc), User, and Day. There is no way to look up the type of FileMetric data you want. This could be a problem in the future if we ever generate DocBook FileMetric or JSP FileMetric. Or, we could do an analysis over all types of FileMetric data, because they inherit from the same parent.
However, I don't think we really need to introduce Hierarchical SDTs to accomplish what you explained. Couldn't we just index the SDT entries by Type (FileMetric, UnitTest, Coverage, etc), User, Day, and Tool? Maybe that doesn't work. How about Type, User, Day, and some other attribute that indicates the Subtype. You could get the specific entries for a subtype or get all types.
To conclude. I like the benefits of your idea. But, I'm not sure I agree with changing the SDTs to get them. Imagine the horror we would live in if we had 50 SDTs! Imagine writing the DocBook for that.
thanks, aaron
At 11:59 PM 3/14/2005, you wrote:
Hi.
Following idea: As we want to introduce these evolutionary sensor data type, which is a lot of work and a major refactoring of the whole sensor data type thing, how about including SensorDataType hierarchies in that update.
So my idea is defining inheritance mechanisms for data types.
So, for example, there could be a BaseSensorDataType, which has only the most common attributes (like timestamp or origin). Then there could be a FileMetricSensorDataType, which is a subtype of BaseSensorDataType, containing very general filemetric attribute. Then you could define things like a JavaFileMetricDataType or a LatexFileMetricDataType which are subtypes of FileMetricDataType.
The fancy thing would be that you should be able to do analysis over all FileMetricDatas in a general matter by casting them to the FileMetricSensorDataType supertype, or do a fine grained, tool based analysis by using the tool subtypes.
So in the end, we would have some kind of fancy sensor data type inheritance tree (just like in Java).
I just thought about that; I don't know if you think if this might be cool. Neither do I know if the rework effort needed for that is justified by just the coolness factor.
Cheers, Christoph
