Talk:ESciDoc Services ContextHandler
December 2007
in progress
Data model and schema update[edit]
- Admin descriptor is not mandatory for context
- To be discussed: split between context and admin descriptor, admin descriptor to be separate object referenced in a context and dependent on the existence of the context i.e. admin descriptor should be deleted when a context is deleted.
New methods[edit]
- Context.close
- A context can be closed only if in status "opened".
- New privileges can no longer be assigned for this context nor new items can be created in that context.
- Existing items in this context can be updated and can finish started publication workflows.
- context can not be updated after closure
- Context.(retrieve-create-update-delete)AdminDescriptor
- In case we decide to split admin descriptor from context, see proposal in data model and schema update
- update admin descriptor to be allowed if context in status created, opened
- delete admin descriptor to be allowed if context in status created
- additional methods, improvement of existing methods (admin descriptors, possibility to add new context types e.g. CitationStyles, Validation)--Natasa 17:08, 16 November 2007 (CET)Clarified partly: Context types are not limited.
updates of methods[edit]
- Context.retrieveContexts
At present this method returns all contexts depending on the filter criteria (context type, role, public-status, user), where "role" criteria can only be provided with criteria "user". This method should be modified in a way that a "user" criteria is mandatory. Not clear from the specification if this is the case (the logic of retrieval in case when "user" criteria is given is fine). The following statement in the spec is not clear "After creating the filtered list of objects the AA component filters this list again in respect to the role of the requesting user. This final filtering is not done in the related "Refs"-method which returns a list of references instead of complete objects. There you will get the complete list"
- Context.delete
In the specification the following is stated: The context has to be in public-status "created", otherwise the removing of the context will fail. The admin descriptor associated with that context will be deleted.The content will be removed from IR. It should be clear that contexts can be deleted only in status "created" and that in that time there are no Items/Container allowed to be created in a context. Admin descriptor of this context should be deleted when the context is deleted.
- Context.retrieve, Context.update
At present this method returns the context and its admin descriptor. There are several use cases for retrieval:
- retrieving/update of context descriptive details (i.e. context properties)
- retrieving/update of context for configuration purposes (i.e. admin descriptor)
- To be discussed: is there a need to split these cases or it makes sense to allow every user who can see/update the context name and description to also see/update the context admin descriptor?
- Context.retrieveMembers, retrieveMemberRefs
- Filters should be uniformly supported for all retrieve lists operations: Context.retrieveMembers, context.retrieveMemberRefs, Item.retrieveItems, Items.retrieveItemRefs and container.retrieveMembers, container.retrieveMemberRefs, container.retrieveContainers, container.retrieveContainerRefs
- Filters should be supported via SRW/SRU search interface with sort, offset and limit parameters
Admin descriptor[edit]
Note: this section is valid for both Container, Context related admin descriptors!
- are there admin descriptor settings relevant for the core services at present?
- Relaxing the admin descriptor structure is important from following reasons:
- allowing to the owners of the admin descriptor to define the internal structure of admin descriptor makes core service of Context/Container more flexible and allows better freedom to client services
- most probably only solutions will now how to handle respective admin descriptors and how they need to define these admin descriptors
- most probably admin descriptor structure can differ based on "label" (i.e. model, type) of the admin descriptor, such as:
- publication collections have one need to structure admin descriptor
- faces have another need for admin descriptor
- some solutions may have no need for admin descriptor at all
- admin descriptors structure are most probably different from one solution to another, but also within a solution, depending on the type of the context/container for which the admin descriptor is associated
- example: validation service works with the concept of a validation context (note: this is not the core services context, but is an XML resource we would like to store in eSciDoc repository). This context is referenced in one or more Contexts of type pubCollection. We would like to add this information in admin descriptor. with current setup of admin descriptor - this means we have to change the admin-descriptor.xsd.
Member lists[edit]
To be discussed: General members list for each member should contain the following information:
- id, pid of the member (current: status: id provided at present only)
- id of context (if member is from Container)
- type of member (item, container) (current status: provided by element item-ref, container-ref distinction)
- cmodel reference of member
- member-properties (common escidoc properties, including title derived from dc:title)
- links to members (or "has members"?)(in case of container members only)
- links to components (or "has components"?)