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

[Jim Eng]

I finished the top-down view.  While doing that, I found a couple  
minor errors and will correct them in the next version.  But I'll wait  
a few days before creating a new version to give people a chance to  
look at this version.  Please take a look if you are interested in the  
import/export capability.

Thanks.

Jim


On Sep 11, 2009, at 5:23 PM, Jim Eng wrote:

> 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/20090912/7e2f5369/attachment.html