Hi Steve
Well, you could do this with decorators at the moment. Having both
decorators and special validation decorators in the spring config file
is somewhat messy, I think. Have you removed the decorators?
Do you hook the data change itself, or the API method? If the API
method, how does this work with the REST methods that invoke multiple
API methods. If you hook the data-change, then how do you do so?
Besides, how do you expect to validate the object, without making the
changes? The way I see it, you will have to commit the changes, do the
validation, rollback the changes if the validation fails.
I would like to know more about how you have managed to work around
this? Or do you just rollback, and leave the mess in the audit stream?
Yes, the java object being validated should work for most things, but
you have to be really careful about managed datastreams and the like,
which may or may not exist before the change is committed.
Remember the curious case of the interdependent objects
A depends on B. B depends on A. Neither is valid until both exists. How
will you ever ingest them?
We have solved this by only requiring validity from Active objects. This
is implemented with a decorator, doing validation when the object is
modified to Active. Are your new hooks as finegrained? Ie, can I hook a
method to do validation if the parameters have special values?
Basically, do you work from the "One set of rules for the entire
repository" mindset, or from the "Several heterogeneous collections in
the repository" mindset?
And of course, validator user rights. Since we do support an advanced
rights model in fedora, validation can fail because you do not have the
rights to view the nessesary data in to objects or from it's relations.
Should the validator use the invoking users rights, or root rights? If
the validation crashes, the change should be refused, I guess.
I will look at your code later, when I can find the time.
Regards
On 01/27/2012 11:20 AM, Stephen Bayliss wrote:
I've made some validation enhancements as per
https://jira.duraspace.org/browse/FCREPO-1026, these are currently in
the fcrepo-1026 branch on GitHub. Some documentation is in the Fedora
3.6 documentation space at
https://wiki.duraspace.org/display/FEDORA36/Validation
I've some questions on how far to take this, so feedback is welcomed.
The current implementation:
* allows configuration of the XML ingest validation via a new
DOManager fedora.fcfg parameter (with a suitable warning in the
documentation about decreasing the level of validation)
* allows all objects to be validated when they are modified, with the
API operation being failed if the resulting object would be invalid
Object validation is configured via spring (see doobjectvalidator.xml
in the server/config/spring directory) - by default it is turned off,
so out-of-the-box there's no performance hit. This feature enables
for instance ECM validation to be turned on for every object
modification to enforce repository content conformance with the CModel
specification via ECM. Certainly this isn't for everyone, but there
are use cases. Custom validators can be written and added that
validate the Java Fedora object (rather than the XML). Any number of
validators can be added, these will execute in turn until (if) one fails.
Questions and thoughts:
* HTTP response code for REST API operations: Currently if an ingest
fails XML validation this is reported via HTTP status code 500 (Server
Error). To maintain consistency with the existing behaviour, object
validation failures will also result in this code, with the text of
the exception containing details of the validation failure. I'd
suggest that maybe 400 - Bad Request [1] might be more appropriate for
both of these; but this would essentially represent a REST API change
- would that be acceptable for a Fedora 3.6 release? If this change
was made I'd suggest implementing this by catching
ObjectValidityException at the API level, and extending this exception
to contain details of the validation failure for the response body
(rather than the 500 exception reporting that occurs currently).
* Validate API method. Currently this performs the ECM validation as
it did in previous releases. This could be modified to perform object
validation as specified in the spring config for this - would this
make sense? It should be configurable so that custom validation can
be plugged into the validate API method *without* enforcing validation
on object commital of course.
* Comments on the implementation and code in that branch are most welcome
Thanks
Steve
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
