Looking at the Capabilities methods, I think there can be some
simplification.
I also pretty sure no applications actually use the capabilities
features but I'm just picking out the safest route in this proposal.
Note that GraphReadOnly does
Often, the meaning depends on the combination of graphs so for example
"iteratorRemoveAllowed" all depends. So it is not reliable.
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
boolean handlesLiteralTyping();
This is purely internal:
boolean findContractSafe()
has one use, for bugs that were resolved(?) pre-Apache according to the
comment. I don't know what the contract is. It is used by InfGraph.
There is a test but I don't know what it is testing for.
PrettyWriterTest.test803804 - it just seems to test that the Abbrev
graph response it to and not the root cause.
Not used as far as I can determine:
boolean addAllowed( boolean everyTriple );
This is used by InfGraphs:
boolean deleteAllowed( boolean everyTriple );
though I can't find out what it means. I pretty sure no app uses it
(what would it do in response to "false"?)
These seem reasonable or are in-use:
boolean addAllowed();
boolean deleteAllowed();
boolean sizeAccuruate();
Proposal:
deprecate prior to removal:
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
boolean handlesLiteralTyping();
boolean addAllowed( boolean everyTriple );
boolean deleteAllowed( boolean everyTriple );
Andy
From before:
https://lists.apache.org/thread.html/6d26dd787e5678aa3a9b1f17194f44a7204425c0f51667d54f8d6bf7@1378035422@%3Cdev.jena.apache.org%3E
