Schematron and Global Context Item Pattern Confusion

58 views
Skip to first unread message

Alexander Stein

unread,
Nov 6, 2020, 5:30:01 PM11/6/20
to XSpec

Hello,

I am new to XSpec but it has been incredibly useful thus far. Thanks for such an amazing tool!

I am trying to use the documented global-context-item pattern by way of your examples to write tests with Schematron. My Schematron will have additionally a dependency on global param (not just the global-context-item) to load a path of relevant XML files with a collection() call to pull in definitions that can change to meet my needs.

Additionally, based on an XPath query, which I would like to only call in the global context, I want to pull in different external data conditionally, with doc() calls, contingent on this global variable's variable such that it keys on the right external file (profile-map and profile-lookup).

The Schematron is here:


The XSpec is here:


The example XML is now inline, but I have moved away from a relative href approach to this file to more granularly test the data for a unit test. Previously I was using this file, but do not anymore. Is this possible or considered a code smell? This error appears to happen regardless; the Schematron global declarations seem to be empty and unbound. Feedback welcome!


So what happens?

I am able to get some of the collection work, but other dependent variables, as I learned through debugging, that my global variable handling the XPath to choose a category that loads the correct profile map is not being evaluated, or at least not correctly.

Below is a screenshot and a copy of the XSpec HTML output is accessible through the Github Actions CI Zip archive I have set up (inside this folder, test/test_all-result.html). If there is a better way to condense this information, let me know.



Am I missing something obvious? I cannot get my selected-sensitivty-level to work and maybe not the profile. I am knew to this, so I presume I am not understanding the global-context pattern property well.

I appreciate any help and thanks in advance for your help.





Notice: The information contained in this message or any attached document is confidential and intended only for individuals to whom it is addressed. If you got this message in error, please inform me immediately using one of the methods above. In some cases, I may ask you to return the documents at my expense. In general, please simply destroy the information at once. Any unauthorized use, distribution, or copying of this information is prohibited.

AirQuick

unread,
Nov 19, 2020, 8:06:43 AM11/19/20
to xspec...@googlegroups.com

> <x:expect-assert id="incomplete-implementation-requirements" label="it is invalid."/>

This x:expect-assert returns Failure, because the corresponding sch:assert/@test in ssp.sch is always true:

> <sch:assert id="incomplete-implementation-requirements" test="true()">

Note that x:expect-assert searches SVRL for svrl:failed-assert. Setting test=true() in sch:assert will not raise it.


Regarding the global context item,

In your case, I think the global context item and x:context must be identical. But the source of the global context item ($global-context-item) is global across all x:context. So, I'm afraid that you have to split the scenarios and put each scenario into its own .xspec file. For example:

[scenario1.xspec]
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec" schematron="../src/ssp.sch">
    <x:param name="allow-foreign">true</x:param>
    <x:param name="global-context-item" select="/">
        <system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0">
            <system-characteristics>
                <!-- no level set in empty element-->
                <security-sensitivity-level />
            </system-characteristics>
        </system-security-plan>
    </x:param>
    <x:scenario label="For an OSCAL FedRAMP SSP">
        <x:scenario label="when the security sensitivity level">
            <x:scenario label="is not defined at all">
                <x:context select="$global-context-item" />
                <x:expect-assert id="no-security-sensitivity-level" label="it is invalid."/>
            </x:scenario>
         </x:scenario>
     </x:scenario>
</x:description>

[scenario2.xspec]
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec" schematron="../src/ssp.sch">
    <x:param name="allow-foreign">true</x:param>
    <x:param name="global-context-item" select="/">
        <system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0">
            <system-characteristics>
                <security-sensitivity-level>low</security-sensitivity-level>
            </system-characteristics>
        </system-security-plan>
    </x:param>
    <x:scenario label="For an OSCAL FedRAMP SSP">
        <x:scenario label="when the security sensitivity level">
            <x:scenario label="is set to a value from the official FedRAMP list">
                <x:context select="$global-context-item" />
                <x:expect-not-assert id="invalid-security-sensitivity-level" label="it is valid."/>
            </x:scenario>
        </x:scenario>
    </x:scenario>
</x:description>

[scenario3.xspec]
...

[scenario4.xspec]
...



@run-as=external introduced in XSpec v2.0 enables you to finetune the global context item in some cases. Unfortunately it is not available on Schematron. I opened an issue for it: https://github.com/xspec/xspec/issues/1287


-- 
AirQuick
--
You received this message because you are subscribed to the Google Groups "XSpec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xspec-users...@googlegroups.com.

Alexander Stein

unread,
Nov 19, 2020, 11:44:24 PM11/19/20
to XSpec
On Thursday, November 19, 2020 at 8:06:43 AM UTC-5 AirQuick wrote:

> <x:expect-assert id="incomplete-implementation-requirements" label="it is invalid."/>

This x:expect-assert returns Failure, because the corresponding sch:assert/@test in ssp.sch is always true:

> <sch:assert id="incomplete-implementation-requirements" test="true()">

Note that x:expect-assert searches SVRL for svrl:failed-assert. Setting test=true() in sch:assert will not raise it.

Apologies, that was foolish. Thanks for pointing it out!
Thanks for the concise explanation and letting me know. I will try that approach and follow this issue you provided. Thanks so much.

Alexander Stein

unread,
Nov 25, 2020, 1:07:36 AM11/25/20
to XSpec
FYI,

I tried even removing my all-encompassing ssp.xspec and declared 1.xspec and 2.xspec, modeling your example, just focusing on these two. I then import only 1.xspec and 2.xspec in test_all.xspec and remove ssp.xspec, and it complained of overlapping global variables, so I am not certain this works either. Should I report a bug?

> Converting Schematron into XSLT...
> Error at /xsl:stylesheet/xsl:param[3] in declare-variable.xsl:
> XTSE0630  Duplicate global variable/parameter declaration (see line -1 of
>  file:/Users/username/Code/fedramp-automation/resources/validations/lib/xspec/src/compiler/xslt/declare-variable/declare-variable.xsl)
> Error at /xsl:stylesheet/xsl:param[2] in declare-variable.xsl:
>  XTSE0630  Duplicate global variable/parameter declaration (see line -1 of
>  file:/Users/username/Code/fedramp-automation/resources/validations/lib/xspec/src/compiler/xslt/declare-variable/declare-variable.xsl)
> Error at /xsl:stylesheet/xsl:param[3] in declare-variable.xsl:
>  XTSE0630  Duplicate global variable/parameter declaration (see line -1 of
> file:/Users/username/Code/fedramp-automation/resources/validations/lib/xspec/src/compiler/xslt/declare-variable/declare-variable.xsl)
>  In template rule with match="document-node(element(Q{http://www.jenitennison.com/xslt/xspec}description))" on line 31 of schut-to-xslt.xsl
> Duplicate global variable/parameter declaration (see line -1 of file:/Users/username/Code/fedramp-automation/resources/validations/lib/xspec/src/compiler/xslt/declare-variable/declare-variable.xsl)

AirQuick

unread,
Nov 25, 2020, 12:46:54 PM11/25/20
to xspec...@googlegroups.com
/x:description/x:param/@name must be unique, even when you declare it in
separate .xspec files and x:import them.
So, instead of x:import'ing them, you have to run each .xspec file
separately.

--
AirQuick
Reply all
Reply to author
Forward
0 new messages