Replace custom orchestration with metaschema-xslt Maven strategy

[aj-stein-nist]

Description:

Switch to Maven, closes #1.

Final check:

Within the scope of work,

• All readme files and documentation resources are current
• Initial comments look reasonable
• Everything touched has been checked for parsing as appropriate (wf/valid)
• Scripts are all executable (permissions +x)

---

ℹ️ To update permissions on all *.sh files via git (from project directory):

$ find . -name '*.sh' | xargs git update-index --chmod=+x

[aj-stein-nist]

Waiting on usnistgov/metaschema-xslt#73 (review) to circle back and adjust approach here for this specific repo.

/cc @wendellpiez

[wendellpiez]

What I think we've learned is (a) irrespective of Maven, XProc 1.0 support for iXML functionality inside XSLT is possible but would entail patching (Java/config), while (b) just about everything else could be straightforward given what we have so far.

So let's proceed to port everything but the extended XSLT under XML Calabash, namely the extended XSLT in Saxon and the Calabash iXML XProc (not XSLT) extension.

Accordingly I suggest we refactor this Issue as follows:

• ignore invisible-saxon.xpl for now, after documenting it as a tbd
• Nearer term we port these scripts to use Maven instead of straight-up Java calls:
  • test-saxon.sh calls SaxonHE with CoffeeSacks support
    • 'classic' architecture, i.e. single XSLT, single XML source, runtime parameters
  • test-xproc.sh runs an XProc pipeline consuming iXML
    • XProc architecture requires a pipeline which defines ports - the pipeline here is ixml-basic.xpl, which requires no input and has a single output port called result

While this doesn't get us all the way there, this introduces no new blocks while it achieves the goal of removing dependency on jar files maintained locally.

As a follow-on we want an XSLT such as ixml-demo.xsl to function inside an XProc pipeline - which requires registering CoffeeSacks with XML Calabash.

When usnistgov/metaschema-xslt#73 is in, we can also discuss XSpec support and how to get iXML into an XSpec stack. While that has certainly been a complicating factor for this Issue I am glad to see it's not actually among acceptance criteria. (But that branch also contains models for all these scripts calling Maven.)