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

[Jim Eng]

I have posted a new draft of the proposed schema.  There's a link to  
it near the top of this page in Confluence:

http://confluence.sakaiproject.org//x/Hw-tAw

The significant changes are that I added the "update_policy" attribute  
to EVAL_DATA element and reworded documentation of EVAL_DATA element  
to make it clearer that certain top-level elements within the  
EVAL_DATA element may contain one or more elements.  The  
"update_policy" attribute is my attempt to deal with the issue I  
mentioned yesterday about the behavior of the import utility when  
attempting to import an element that already exists within the system.

All of this is a proposal and open for discussion and revision.

The Confluence page contains a link to the XML Schema for Version 005 (http://www-personal.umich.edu/~jimeng/eval_data005/eval_data.xsd 
) and a link to the html documentation for Version 005 (http://www-personal.umich.edu/~jimeng/eval_data005/eval_data.html 
).

The Confluence page also contains a link to top-down view of the  
latest version within Confluence (http://confluence.sakaiproject.org//x/TBDtAw 
).  That is my attempt to make it easier for people to comment on  
details of the proposed schema or propose changes and additions. I  
would guess that this top-down view is about one-third done.  In other  
words, I have added about one-third of the pages that will be needed  
to fully document the proposed schema.

You're invited to look through these pages, add comments, suggest  
additions, suggest revisions, etc. If you find it easier to work from  
schema itself (http://www-personal.umich.edu/~jimeng/eval_data005/eval_data.xsd 
) or the html documentation for the schema (http://www-personal.umich.edu/~jimeng/eval_data005/eval_data.html 
) and then send comments by email, you're welcome to do that. Or you  
can add comments to the main confluence page (http://confluence.sakaiproject.org//x/Hw-tAw 
).

Thanks.

Jim



On Sep 10, 2009, at 5:43 PM, Jim Eng wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20090911/dfeeed7c/attachment.html