[gradebook2-dev] Gradebook, object names, case-sensitivity

Jon Gorrono jpgorrono at ucdavis.edu
Sun Jan 22 19:10:10 PST 2012


Not sure I really addressed your question... so, let me ramble on :)

After someone successfully creates two items using edu-services
gradebook API's, gradebook2 asks the same API for a list of items and
does not do any triage on them from the perspective of text case.

I know of a few weird things that come out of that; you can't delete
any item that matches another when disregarding case, for one example.
But there should be more things.... to get a full inventory we can let
some creative soul loose in the UI to make exploit the problem....

As I mentioned, we could solve the delete problem, but not applying
the business rules associated with same-nameness before deleting... we
would also have to deal with each new strange thing that someone
finds.... that was the point I rushed into in my last email

On Fri, Jan 20, 2012 at 10:07 PM, Jon Gorrono <jpgorrono at ucdavis.edu> wrote:
> If they are identical in name and case, edu-services would not allow
> it ... if they differ only in case, then it would allow it... and,
> that could also happen with just a single tool source
>
> ... rather than try to wrangle all the loose cattle that this
> discrepancy (btwn gb2 and edu-services case handling) might let loose,
> I was hoping to close the gate :)
>
> But, in the absence of getting that to happen, one draconian
> gate-closer is to refuse to load all such items (items that differ
> only in case)
>
> another more complex and code-intensive approach is to offer to merge
> them or otherwise ask the user which one to keep.
>
> WDYT?
>
> On Thu, Jan 19, 2012 at 8:57 PM, Jim Eng <jimeng at umich.edu> wrote:
>> A question, Jon:
>>
>> Suppose two external apps contribute gradebook items with the same name
>> (i.e. two items from different sources with the same names in the same
>> case). How does GB2 handle that?
>>
>> Jim
>>
>>
>> Connected by DROID on Verizon Wireless
>>
>>
>> -----Original message-----
>>
>> From: Jon Gorrono <jpgorrono at ucdavis.edu>
>> To: gradebook2-dev at collab.sakaiproject.org
>> Sent: Fri, Jan 20, 2012 04:46:42 GMT+00:00
>> Subject: [gradebook2-dev] Gradebook, object names, case-sensitivity
>>
>> I didn't get any bites on this in OAE-DEV....
>>
>> So, I'll float it here for discussion... suggestions for ways to move
>> forward appreciated.
>>
>> We (UCD) are rSmart clients and I think they have vendor dropped
>> edu-services, maintaining some changes... so *we* may end up with that
>> as *our* final form of the proposal, but it would prob be better if we
>> had a more general approach ruled out first....
>>
>> A short intro to the problem: external tools can add gb assignment in
>> upper or lower case and they are treated as separate.. gb2 is
>> case-insensitive... so, trying to delete one of two or more items that
>> differ by case only is not currently possible in gb2... it is just
>> confused.
>>
>> This is the last case found outstanding for GRBK-1204
>>
>>
>>>Greetings OAE/kernel warriors :)
>>>
>>>There was some discussion, some time ago, about case-sensitivity in
>>>gradebook (edu-services gradebook, now) with a minor movement to make
>>>the items there case-insensitive (they are now case-sensitive: "essay"
>>>does not imply "Essay")
>>>
>>>Our user community seems to almost unanimously assume that have the
>>>label "Essay", as in the example, should be treated as identical to
>>>"essay".. this is, no doubt, in no small part due to Gradebook2's
>>>being initial designed with that assumption (good or bad) :)
>>
>>>Gradebook2 plays the role of an improving-with-time gatekeeper wrt
>>>names of items that originate in it's UI... but items created in other
>>>tools that interface directly with edu-services pose an interesting
>>>challenge to gb2... one we would like to avoid :)
>>>
>>>If there is still 1) support for the change to edu-services to ignore
>>>case in comparisons and 2) a reasonable way that can be found to move
>>>forward with reconciling/merging existing items that would then be
>>>considered duplicates, we would be glad to do any actual work that
>>>might entail.
>>
>>
>>
>>
>> --
>> Jon Gorrono
>> PGP Key: 0x5434509D -
>> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
>> GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono www.gswot.org>}
>> http{middleware.ucdavis.edu}
>> _______________________________________________
>> gradebook2-dev mailing list
>> gradebook2-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>>
>>
>
>
>
> --
> Jon Gorrono
> PGP Key: 0x5434509D -
> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
> GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono <jpgorrono -
> www.gswot.org>}
> http{middleware.ucdavis.edu}



-- 
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono <jpgorrono -
www.gswot.org>}
http{middleware.ucdavis.edu}


More information about the gradebook2-dev mailing list