A discussion of the design and implementation of an RDF API.
It's easy to say what sort of behaviour we consider reasonable when we use an RDF API as outlined above in a simple, single-threaded manner which disposes neatly of one iterator before creating the next.
What is harder, however, is to specify the precise behaviour that we expect should we, for instance, remove half of the triples in a model that underlies a TripleIterator part of the way through using that iterator. Should this be an error (error semantics)? Should the iterator remain unchanged (snapshot semantics)? Should remaining calls to the iterator reflect the new underlying model (view semantics)? In the latter case, we also need to decide what happens when the triple currently pointed to by the iterator disappears. Does it force an immediate and implicit call to the iterator's next() method, or does the current triple survive?
These are questions which the provider of an implementation needs to consider - and supply answers to! However, it would be an error to attempt to do more than outline the potential pitfalls here since in doing so, we'd be limiting the options available to future implementors and possibly proscribing potential efficiencies that could be made.
In other words, leave it up to the implementor to make these decisions to support one (or possibly more) of the potential semantics; providing those decisions are adequately and accurately documented then the potential user of an implementation can decide whether it satisfies their requirements.