[Contrib: Evaluation System] Proposed XML schema for import/export of evaluations

[Jim Eng]

Our fourth draft is here:

http://www-personal.umich.edu/~jimeng/eval_data004/eval_data.html

The first three drafts were just to get it to the point where it  
documents fairly well what Dick Ellis implemented in the Michigan  
branch, with a few extensions or changes we plan to make before  
merging it to trunk.  Dick implemented code to import files in this  
format.  Export has not yet been done.

Some eval model classes are missing from this schema because they are  
not needed at Michigan.  If you want additional types added to the  
import/export capability, please let me know and I will add them to  
the schema.

I would appreciate help working through the lists of properties for  
each type of element to ensure that they are correct.  If a property  
is not needed in some cases and is needed in others, it should have  
minOccurs set to 0.  If a property is always required, minOccurs is  
not needed (since the defaults for both minOccurs and maxOccurs are 1).

I would like to raise another issue having to do with the behavior  
when an element defines an object that is already defined in the  
system.  We have discussed three possible responses:

1) reject the changes (i.e. make no changes in the current state of  
the object and report an error)

2) make the changes in the existing object (but not in other objects  
that might depend on it)

3) make the changes and cascade them to all objects that depend on the  
changed object.

An example related to options 2 and 3 would be when an import file  
includes a definition for a template that already exists in the system  
(i.e. same EID as an existing template).  The original import  
implementation at Michigan replaced all property values of the  
existing template with the new values and then also changed the values  
in all evaluations that referred to that template.  That is described  
by item 3 above. It produced unexpected results that were wrong in  
some cases. Dick then removed the cascading capability, giving us  
something like item 2 above.  That works better, but now we are  
changing policies so changes are effected by replacing the old item  
with a new item (i.e. a different EID).  In that case, most attempts  
to change an existing item from an import file are invalid and should  
be rejected.  That is best described by item 1 above.

We could implement the import utility to effect any or all of these  
policies.  I think it makes most sense to control it with a property.   
It could be a system-wide setting.  Or it could be an attribute of the  
EVAL_DATA element:

<EVAL_DATA duplicate_policy="reject">
	...
</EVAL_DATA>

<EVAL_DATA duplicate_policy="accept">
	...
</EVAL_DATA>

<EVAL_DATA duplicate_policy="cascade">
	...
</EVAL_DATA>

We would need to work out some details about each one.

Thoughts?

Jim