It's hard to find many uses in the main code base of capabilities. I
can only find two uses in main/java at all:
* use of sizeAccurate() in the isomorphism code
* findSafeContract() in RDF/XML writing.
Otherwise it's all in the testing code.
Oddly, it does not seem to be reflected in the Model API.
The Inf code seems to provide them - but is it used?
Conclusion: a feature that is not worth it.
I think the principle should be easy implementation for new storage
systems. A simple, straight forward graph interface would be the way to go.
This is not saying Capabilities are wrong - when the world was simpler,
the idea of Capabilities made sense. The overall system has moved on
and is too complicated for the idea central set of features which are
either provided or not.
e.g FileGraph - it claims to provides transactions (which isn't even a
capability! Details.). Actually, the transaction contract is quite hard
to provide and the code can be useful without full crash-resistance.
To support testing, there is an alternative of providing test suites
that cover the ideal correctly, simple and cleanly.
If some subsystem wants to opt out of some tests, it inherits the tests
and stubs out the parts it does not want to provide. And documents it
somewhere (FileGraph says it supports weak transactions).
@Test public void somefeature_01() { /* Choose not to support this */ }
Now, we have a test collection that is simpler and the responsibility is
moved to the subsystem. The test suite captures the true contract.
there is no central concept of global variations. It's very hard to
define the right set of capabilities that is both general and reflects
real choices.
e.g. TDB (nor SDB) never provided "minimal" or "complete" styles of
reification (again, was not a capability!). Both require additional
persistent state to be kept and that is a huge amount of work for
features that were, at best, rarely used. They both simple stubbed out
the tests that needed those modes.
Mode "standard" and is done by calculation only, no persistent state.
Having seen the amount of work the RDB layer had to do to provide the
features, it was clear to me it was not worth it and certainly not worth
holding up release until every feature was done.
Where else can we simplify the base system?
Andy
