Metaschema Metapath minimal feature set / PoC

[wendellpiez]

User Story:

Under usnistgov/metaschema#39 we are working on constraints definition and support for constraints checking in Metaschema.

Our initial intent is to shortcut the problem of addressing nodes (for assertion of constraints) by using an XPath subset, which we can later extend or generalize.

Goals:

For this Issue we need to stand up a minimal PoC of an expression language supporting basic addressing in the context of Metaschema.

Starting with a small subset of XPath makes sense. It needs to be able to support at least basic traversal and value testing, e.g. verse[@type='quatrain']/line[@feet='5']

Dependencies:

This issue is a dependency for #12 and hence for usnistgov/metaschema#39 as well.

An end-point dependency for this Issue is a boundary around the feature set for the addressing syntax. We will start small and work up.

Prior art

We can save work by doing this right, probably with a grammar for our syntax.

David Carlisle library parsing XQuery: https://davidcarlisle.github.io/xq2xml/
XForms 1.4 has a parser for XPath 1.0 in XSLT: https://sourceforge.net/projects/xsltforms/
Email from John Lumley to XSL-List Re: [xsl] Parsing XPath in XSLT? March 26 2020

Acceptance Criteria

A fully working solution is not an acceptance criterion for this Issue!

• We have a demonstration / PoC showing addressing working to support constraints checking from Metaschema. It works on the XML side and we can show its feasibility on the JSON / object side.
• We have created appropriate spin-off Issues including further defining the boundaries of this effort
• All website and readme documentation affected by the changes in this issue have been updated. Changes to the website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[wendellpiez]

Lumley's specific advice:

The simplest is to use Gunther Rademacher's REx parser (https://www.bottlecaps.de/rex/) to generate an XSLT parser for XPath3.1. To do this download the sample grammar for XPath31 (left hand column on the page) then generate the parser using XSLT as the target, backtracking on, and parse tree checked on Generate Code. Hitting 'Generate' should produce a download of a file xpath-31.xslt, which contains internally a function p:parse-XPath($expression as xs:string) as element() [xmlns:p="xpath-31"].

In his email he is more explicit on how to approach next steps as well.

[wendellpiez]

Suggested by experts on XSL-List (JL and one or two others) this looks like a good way forward.

Using the xpath20.ebnf as provided for (by) REx, we should be able to parse XPath 2.0. That gives us leverage for mapping the syntax from Metaschema into the target Schematron or JSONatron. We can try this out sooner and refine it later.

Using a stripped down EBNF we can also produce a smaller parser. Even before we do that, we could use an additional filter (function) with a syntax check, to define the permissible subset.

[wendellpiez]

https://www.bottlecaps.de/rr/ui provides an XPath 1.0 EBNF as well as some nice tooling.

[wendellpiez]

April 8 Update

Much progress on this in the last few days:

• We can now parse XPath 2.0 but also a reduced "minipath" language supporting only a smallish subset
• By parsing, we can effectively decompose paths for purposes of mapping
• A function to provide for mapping namespace prefixes has removed the blocking dependency on this Issue cf Metaschema constraints definition and enforcement #12 Metaschema refactor phase 1: towards v2 metaschema#39
• A set of XSpec unit tests provides regression testing over this functionality

Suggest we look at acceptance criteria to determine next steps.

[wendellpiez]

This is working. The grammar looks sound, with only a single remaining known question:

• How can we remove the production supporting node tests selecting XML processing instructions, namely the XPath processing-instruction('target') node test? When I have tried to do this, the EBNF has blown up on me.

This is not a disabling bug; it only means the grammar includes a production it does not need. We can filter out the syntax at the application level if we need to.

If we resolve this question, decide not to resolve it, or move it to a new Issue, we can close this Issue, since except for datatype support (now being tracked in usnistgov/metaschema#50), this work item is otherwise complete for a first phase. @david-waltermire-nist what say you?

Tracked by usnistgov/OSCAL#633.

[wendellpiez]

This Issue has been addressed to the extent implementation is currently planned.

Specification of Metapath needs another Issue. This one can be closed.