`has-oscal-namespace()` function in Metapath

[wendellpiez]

User Story:

Because straight-up XPath seems a little cumbersome and to reflect its special semantics, we proposed wrapping the test for the oscal namespace (@ns flag) in a function has-oscal-namespace() which is indeed called in OSCAL.

https://github.com/usnistgov/OSCAL/blob/534b12dca5da4223615b72677159528022aa344a/src/metaschema/oscal_catalog_metaschema.xml#L52C77-L52C108

Couple of problems with this:

• OSCAL is not metaschema. Does every user of metaschema get to extend Metapath?
• Neither is a flag named ns - this is OSCAL semantics
• It is not clear why this function has an argument or what has-oscal-namespace('some-other-namespace)` should return
• This is taking a big step for a small gain - to implement it properly means parsing the Metapath expression in which it appears, whereas the rest of Metapath (so far) simply casts into XPath, giving us a robust and well-tested specification of semantics to lean on for free (or: only opportunity costs vis-a-vis other possible approaches - which remain open long-term).

Can we consider rolling this back or improving it?

The question is not urgent except it poses a planning problem for metaschema-xslt or indeed any processor that wants to implement constraints testing -- see below under Goals.

Alternatives:

OSCAL could use pure XPath:

• literal test: not(@ns != 'http://csrc.nist.gov/ns/oscal') - no @ns is present not equal to the value
• compound test: empty(@ns) or (@ns = 'http://csrc.nist.gov/ns/oscal') - cumbersome but explicit

or rely on the processor supporting an extended XPath/Metapath:

• custom function oscal:has-namespace() or m:has-namespace()
• function bound to variable: $oscal:has-namespace() or $m:has-namespace()

or continue with a homemade function (presumed Metapath-native, so no namespace is given on the function name) but cleaned up semantics

• has-namespace($ns) instead of has-oscal-namespace($ns) - although this is really doesn't-have-another-namespace() 🤔

possibly other choices I have not thought of.

These are given in order of ease of implementation for the constraints checking, assuming XPath support. (The last option more or less requires implementing Metapath, if not to interpret it, at least to parse its syntax.)

Goals:

More clarity on plans for this function in particular and extensions to XPath in general.

One outcome could be an Issue in the OSCAL repository for making a change to its metaschemas where they use this construct.

Another outcome could be a decision to support or revise the function, with a PR or a spin-off Issue for necessary docs edits.

Irrespective of whether this feature of Metapath can be changed, the metaschema-xslt dev plan for constraints checking will be to build full Metapath support so as not to have this issue again -- with this feature or any other. Shorter term, however, if this feature can be pulled back, something much easier than Metapath can be contemplated for an implementation of Metaschema-based constraints checking.

This is especially true if we could go with a pure XPath approach, and continue to stick better to the rule "All XPath For Now".

Dependencies:

None known. This developer is seeking guidance that bears on implementation strategy.

However, the OSCAL team needs to be consulted. Indeed, they might prefer to use all XPath against a custom function in any case.

(cc @aj-stein-nist @nikitawootten-nist - please circulate as necessary)

Acceptance Criteria

• [ ] 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. OR, this Issue reflects and/or links to sufficient discussion to resolve this issue (short/medium term), and
• [ ] The CI-CD build process runs without any reported errors on any PR. This can be confirmed by reviewing that all checks have passed in the PR.

[david-waltermire]

FWIW, the has-oscal-namespace function is not implemented in Metapath. This is an extension supported in liboscal-java. There is also a resolve-profile function.

I believe has-oscal-namespace could be eliminated by replacing it with the necessary @ns=(namespaces) predicate. If this is done, then the extension function can be eliminated. This work needs to happen in usnistgov/OSCAL and usnistgov/liboscal-java.

For resolve-profile, I believe we need to support custom namespaces for functions as you suggest above, e.g. oscal:resolve-profile().

The latest changes in the Metapath grammar now allow a QName to be used for functions. I am working to add support for this in metaschema-java. Once done, we will have a full implementation of this approach to test with. This work is tied to metaschema-java.

IMHO, other than discussing a general implementation approach, I don't think there is any work to do in Metaschema at the moment. Once we have an implementation approach, we should document this in the Metapath specification, which is still very nascent.

[aj-stein-nist]

FWIW, the has-oscal-namespace function is not implemented in Metapath. This is an extension supported in liboscal-java. There is also a resolve-profile function.

I actually encouraged @wendellpiez to open this issue based on a conversation, so we can say I helped co-authored the issue. That said, I did very little homework before the casual discussion, which I should have done before recommending we open this issue in this repo.

I believe has-oscal-namespace could be eliminated by replacing it with the necessary @ns=(namespaces) predicate. If this is done, then the extension function can be eliminated. This work needs to happen in usnistgov/OSCAL and usnistgov/liboscal-java.

Ironically, I had not checked this and was unaware of it. I presume the answer to Wendell's question is: yes, Metaschema users can extend the core Metapath function set if they have the capability to do so, and for OSCAL this approach has been take with has-oscal-namespace. I should have checked the function was implemented in this library and not in the core metaschema repo, apologies.

For resolve-profile, I believe we need to support custom namespaces for functions as you suggest above, e.g. oscal:resolve-profile().

Good point, that makes a good deal of sense to me.

The latest changes in the Metapath grammar now allow a QName to be used for functions. I am working to add support for this in metaschema-java. Once done, we will have a full implementation of this approach to test with. This work is tied to metaschema-java.

IMHO, other than discussing a general implementation approach, I don't think there is any work to do in Metaschema at the moment. Once we have an implementation approach, we should document this in the Metapath specification, which is still very nascent.

Completely agree and I was the one who didn't do the homework when this was originally discussed. @david-waltermire-nist. ~can we move this to liboscal-java to consider the follow-on work over there, if any? (I saw your updates to usnistgov/liboscal-java#169, so maybe there isn't any or much there, but we can transfer the issue over and update/close accordingly.~ Thanks for the detailed response!

EDIT: I have the ability to transfer the issue myself given my perms, I will do so. No need on your end, Dave.

[wendellpiez]

Excellent, thank you.

In my implementation I will continue on working with the assumption that I can make any solution work as interim, while we balance the concerns. Also happy to help with any rewiring in repositories or indeed in helping with XPath/Metapath in any metaschema, real or mockup. :rocket:

resolve-profile() is pretty heavy, but not an unreasonable use case for an extension function.