Use factories and separate jars for input interpreters

[GoogleCodeExporter]

Use java factories and separate jars for input interpreters.

The reason for this is that these have a tendency to change while the system 
remains the same, and it can generate a lot of new versions.

If separated, those interested in a package of input interpreters can update 
only these, and the system does not have to change version.

Original issue reported on code.google.com by joel.hak...@mtm.se on 26 Sep 2011 at 7:46

• Blocked on: #60

[GoogleCodeExporter]

Original comment by joel.hak...@mtm.se on 21 Aug 2012 at 6:30

• Added labels: Maintainability

[GoogleCodeExporter]

Original comment by joel.hak...@mtm.se on 21 Sep 2012 at 9:48

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by joel.hak...@mtm.se on 23 Sep 2013 at 9:29

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by joel.hak...@mtm.se on 24 Sep 2013 at 7:30

• Added labels: Component-Input

[GoogleCodeExporter]

Original comment by joel.hak...@mtm.se on 30 Jan 2014 at 8:22

• Now blocked on: #60

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This could possibly be solved without solving issue #60 by using dependency 
injections for validation and transformation. This bundle-to-be uses a 
validation component and a transformation component, but it does not 
necessarily have to provide it to itself.

Another solution could be to place the boundary at providing URIs to 
appropriate validation and transformation files for the input source, in which 
case the bundle-to-be does not have to be able to perform either task. This 
solution works well with DP2, as it could return an XML-file containing URIs to 
the XSLTs and schemas for DP2 to run, in other words this would be useable as 
an XProc step. The downside of this is that non-XML files cannot be supported 
directly. One way to handle that is to convert non-XML into some form of XML 
inside the component, and in that case perform some (or all) of the required 
conversions internally. In XProc terminology:

The step has no primary input port, but a secondary input port which defines 
the URI to the input document (may be non-XML).

The primary output port is either the input document (if it is XML) or an 
XML-document that has been created based on the input document (if it isn't 
XML).

There is a secondary output port which provides an XML-document with URIs to 
transformations and validations to run on the output XML-file.

Original comment by joel.hak...@mtm.se on 27 Aug 2014 at 7:02