9/28/2005 SRM conf call

Jlab: Brian, Michael, Chip
CERN: Peter, Sebastian, Olof,
FNAL: Timur
RAL: Owen
Rich
LBNL: Arie, Alex

* Decoration in op spec, functional spec to be as is with behaviour definition

* decoration or XML document?
-- suggestion to appear a function in many places (core and adv depending on the feature supported)
-- avoid overloading return types
-- unix ls for a file or dir : they are similar, but if output is drastically different, better to have a seperate them as different functions
-- it needs to be documemnted in func. spec.  Requirements documents will have which functions to be used
-- func spec not to be overlapped with op spec?
-- func spec needs to talk about parameters for the semantics behaviour. Op spec can repeat that.
-- suggestion: func spec as is. after that, we'll take suggestions to where to put (reformat for each function depending on the supported adv features) breaking a function into different places.
-- Try to disjoint as much as possible
-- func spec to capture the concepts
-- try to find the disjoint functions and put them in different places
-- as long as parameters are orthogonal, then put them in the different places
-- find cases that are sticky and go from there
-- high level description doc is needed with important use cases: what data goes in, what comes out, --> analysis doc, not design doc --> requirement doc which does not name functions or no input details, no op behaviours

-- XML message "schema" for in and out