I would tend to agree with the strangeness of the model ATM. It's kind of like
modeling driving by saying Highway.driveCar() instead of Car.drive(Highway).
It appears (to me) flipped from common logic. I don't know that this itself
argues for creating a service, but it certainly calls out some inflexibility
and non-intuitiveness.
-sf
On May 2, 2011, at 4:07 AM, Graham Triggs wrote:
On 2 May 2011 03:35, Richard Rodgers
<[email protected]<mailto:[email protected]>> wrote:
The data model forces all items to belong to at least one container
(collection) - this is why there is no public item.create() either (which would
allow uncontained items in the repository).
Items can also belong to other containers. Therefore the API requires that
calling code (not just UI code, by the way) manipulate items though a
collection.
And that's one of the worst parts of the data model. Sort of! Sure, it makes a
certain amount of sense that there has to be a container for any item that is
installed in the repository (although 'tagging' is probably better than any
fixed hierarchy) - but because a wrapped Item is used for submission, it means
that you can't simply submit something without a collection, to be organized
later - either automatically from the metadata, or manually by the
administrators / reviewers. This is often desired behaviour (as it takes some
of the barriers away from submitters). It can also become more important with
things like SWORD - let external systems submit 'blind' to a repository, and
let the librarians manage what happens with it.
The authorization model distinguishes regular users (where policies are
checked) and administrative 'super' users ( where they aren't).
The assumption is that most calls are made by regular users of the system with
limited powers. So how would item.delete() work for regular users?
Suppose they had permissions on a linked collection of the item, but not on
the owning collection. Would it fail completely, succeed in removing the item
from collections the user was allowed to do, and leave the rest? The semantics
(contract) of the method become a little more complicated.
The only user that could be assured of success would be the super-user, and
what is the use-case for an administrator deleting an individual item?
Actually, simplistically it could work itself out - you delete from all
collections (linked or owner), and if it any throw an authorization exception
the transaction rolls back and the exception is exposed.
The linked vs owning collection is interesting - of course, you can just
delete/remove from the linked collection if that's what you want. You shouldn't
delete an item in order to remove it from a collection.
There are a couple of reasons for making this a service rather than burying it
deep into the content model. The most important is that it further buries the
restrictions and assumptions of the content model within it - we should want
and be working towards more flexibility in that model. The second, which is
what you've covered, is that to deal with the rigidity of the model you need to
employ a strategy for interpreting the permissions - and legitimately you can
see different requirements in different repositories. Hence, you would want
that strategy outside of the content model where you can easily swap the
implementation.
But this is all fundamentally the problem of having a rigid model, and a lot of
assumptions to cope with interpreting simplistic permissions to keep the model
consistent / make it work. Editing or deleting/withdrawing items should be
determined solely by the permissions of the item (and you can [selectively] add
permissions for users / groups as you map items to collections).
Removing an item from a collection is a distinct operation - it should not be
confused / overloaded with deleting items, it should only be determined by
permissions on the collection, and it should always be possible regardless of
ownership and mapping status. Yes, that means orphan items - but we can always
find ways of dealing with them (eg. event handler for unmaaping collections -
checks for orphan, sends admin email and withdraws item).
G
<ATT00001..c><ATT00002..c>
--
sands fish
Senior Software Engineer
MIT Libraries
Technology Research & Development
[email protected]<mailto:[email protected]>
E25-131
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
