Guys,

I had some problems joining into the test model meeting today. I ended up listening in, but you couldn't hear me. I am concerned about this issue of namespaces and I am unhappy with the current state. Maybe you could clarify.

My understanding is that namespaces were introduced to provide a grouping mechanism for DPLVariables. 

When we did the first cut of the data model we refrained from making it to specific in order to meet the diverse requirements. To quote Joe's meeting minutes we aggreed that the datapooling usage will be quite broad and that 

	"Data from a datapool may be static data that was entered by the 	user, or it may be dynamic data that is evaluated at test runtime.  	This dynamic data may be (or may be influenced by) data gathered 	from the SUT, or from any of the other Hyades models (execution 	history, trace, etc.), or may be the evaluation of some type of 	expression represented in the datapool." 

furthermore 

	"There is a very broad range of data sources from which datapool 	data may be retrieved (examples included in-memory graphs, multi-	dimensional databases, Trace data files and Excel spreadsheets.)"

In short we couldn't be expected to make all the requirements regarding data sourcing and grouping explicit. With regard to data sourcing we decided to introduce an extension mechanism which is available in DPLVariable via the type attribute. The default is 'literal' and the extension point simply returns the value stored in the cell. A vendor could however introduce a type called 'excel data'. In this case, quoting from the meeting minutes again:

	"In the more complex cases, a cell of a given non-literal type 	contains an expression that specifies a value contained within a 	specific data source.  When retrieving the value for this cell, 	the expression is passed to the extension point implementation for 	the cell’s type, and that extension point implementation uses the 	expression from the cell to determine the actual data value.  For 	example, if the cell’s type was “excel data”, the expression in 	the 	datapool might be “c:/temp/finances.xls;$A$6”.  In this 	case, the extension point which is registered to support the 	“excel data” type in the datapool would receive the string 	“c:/temp/finances.xls;$A$6”, would open the finances.xls 	spreadsheet, read out the value in cell $A$6, and return that 	value as the value from that datapool’s cell."

In my view, if there is a need to think about namespaces they should be used with regard to the type(s). I.e. you need to qualify 'excel data', by stating that it belongs in the Excel7.0 rather than Excel5.0 namespace. But this should be up to the vendors and how they define their types and extension points. 

Unfortunately, I couldn't see the model, but if a datapool is a namespace, then all variables belong to that same namespace, which is a constraint, that isn't necessarily true. I can imagine applications of data pools where my variables belong to different namespaces. 
As Gian Franco pointed out, given the model as it stands, a datapool can contain datapools. This complicates the model unnecessarily. 

Finally, the grouping of cells is actually provided by the equivalence class, which again we left flexible. Thus, an equivalence class can be an arbitrary set of constraints that specifies which set of cells is equivalent to another. But this might not have been the kind of grouping that was discussed.

Maybe someone can clarify the motivation for namespaces and we can then discuss further.

	Stefan

--------------------------------------
Stefan Daume
Product Development Manager
Scapa Technologies
+44 131 652 3939