URF needs some general interface to hold the result of URF processing, an abstract "container" for all its statements. Currently the closest thing we have is a SimpleGraphUrfProcessor, which holds one representation of the result of some processing. But its representation needlessly creates and internal series of graphs which may not be needed in a particular context (if we are not reserializing to TURF, for instance).
Currently the best name for this thing might be UrfModel, and I suppose could be an UrfModelProcessor that produces an UrfModel as a result. The interesting thing is that an UrfModel could also be an UrfSource, another new interface that provides a UrfSource.process(UrfProcessor) method to essentially "parse" the model into some other form (into a graph, such as with SimpleGraphUrfProcessor, or even another UrfModel!).
URF needs some general interface to hold the result of URF processing, an abstract "container" for all its statements. Currently the closest thing we have is a
SimpleGraphUrfProcessor
, which holds one representation of the result of some processing. But its representation needlessly creates and internal series of graphs which may not be needed in a particular context (if we are not reserializing to TURF, for instance).Currently the best name for this thing might be
UrfModel
, and I suppose could be anUrfModelProcessor
that produces anUrfModel
as a result. The interesting thing is that anUrfModel
could also be anUrfSource
, another new interface that provides aUrfSource.process(UrfProcessor)
method to essentially "parse" the model into some other form (into a graph, such as withSimpleGraphUrfProcessor
, or even anotherUrfModel
!).