Add support for multiple input files

[jelovirt]

Add support for multiple input files per DITA-OT process.

Multiple input files should work the same was as a single input file with additional resource files, except all resource files are treated as processing-role="normal".

Interface changes

In the CLI, add support for multiple --input arguments.

$ dita -i maps/content.ditamap -i maps/keys.ditamap …

For project files, add support for multiple input fields.

contexts:
- input:
  - maps/content.ditamap
  - maps/keys.ditamap
…

Add args.inputs Ant property:

<pathconvert property="args.inputs">
  <pathelement location="maps/content.ditamap"/>
  <pathelement location="maps/keys.ditamap"/>
</pathconvert>

[jelovirt]

@robander args.input can be either system path or a URI, relative or absolute. I'd prefer to make args.inputs (notice the plural) always be absolute, to make things more simple. If a API in front of the Ant API allows relative paths, then it's up to that layer to resolve those to absolute paths.

However, because Ant doesn't have support for array types, do we want to use properties to be begin with for args.inputs? We could make it a resource collection instead, because Ant resources can be either files or e.g. URLs. But, I'm worried it will be too difficult to use and unnecessarily binds use to Ant.

So, how to handle both URIs and file paths in the same property, because there is no obvious separator character. For paths we can just use the system separators : or ;, but there is no single correct separator for URIs. We can use a space, but then that would not work with paths.

Would it be OK if we defined args.inputs as a list of URIs, separated by e.g. spaces? Either absolute URIs file:///maps/root.ditamap file:///maps/keys.ditamap or with just absolute path parts /maps/root.ditamap /maps/keys.ditamap.

Or have args.inputs and args.inputs.uri, where the former one is system paths separated by system separator and the latter is URIs separated by a space character?

[robander]

@jelovirt Thinking about how I'm most likely to use this in our larger environment, I think URIs would be OK as long as it can take the absolute path:
/test/inputone.ditamap /test/bad%20name.ditamap

I think over time more and more people interact with the command through editors or build scripts, which should be able to hide or translate the values appropriately. Basically, adding that layer ahead of the build to translate paths in a more friendly way.

I'm also thinking about this (for now) as a more complex usage, where it seems more acceptable to enforce stricter rules about the input - maybe others would see it differently?

[jelovirt]

This could resolve #1697

[robander]

Is this going to cause issues with inputs that have spaces in the file name or path? Or do those get normalized to %20 before we reach this point?

[jelovirt]

It's up to the client to pass valid URIs. So if the end user user inputs an invalid URI (a URI with a space) to the client, the client will need to convert it to a valid URI (by escaping the space with a %20) when setting args.inputs property.

[jelovirt]

Dropping from 3.4 release due to lack of interest. Maybe in 4.0