XSLT transformation to convert statement to readable text?

[riknykn]

I'm implementing XSLT conversion of SP 800-53 from XML to another XML format. I'd like to combine all control statement parts to a single text element. Does someone know that has it been already done as part of the tools or should I just try to figure it out? I seems to be quite tricky and I tried to look for existing tools some tips, but could not find. Thanks in advance for any advice.

[sunstonesecure-robert]

Just curious if you have considered json instead of xml? Then you can use things like jq (or of course python or nodejs scripts) As a one time xslt fan and heavy user…I have never missed it since switching

…

On Wed, Oct 6, 2021 at 11:56 PM riknykn ***@***.***> wrote: I'm implementing XSLT conversion of SP 800-53 from XML to another XML format. I'd like to combine all control statement parts to a single text element. Does someone know that has it been already done as part of the tools or should I just try to figure it out? I seems to be quite tricky and I tried to look for existing tools some tips, but could not find. Thanks in advance for any advice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1036>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQWTGFHWNPDVSXQG27PISNDUFVACFANCNFSM5FQQ4EUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[riknykn]

I need to transform to xml to be able to import data into Semantic MediaWiki where I have already some exiting release 4 transformations. I think there is also json import plugin for SMW and it could be possible to change it to json->json conversion, but I would need to rewrite all old transformations, which is little bit too much work. Definitely would consider it, if I would have no existing transformations.

[ohsh6o]

I'd argue that jq is not well-suited to complex transformations. Even in this project, I spent a few days trying to figure out how to do just that with jq in #1010 and doing in place modifications of state was very annoying. You also had to save your place, so I ditched that and went for good old python3.

[ohsh6o]

FYI @riknykn not exactly what you're looking for but the NIST OSCAL devs do publish HTML transforms that might giive you a good idea of what you need to do. Hat tip to @wendellpiez.

https://github.com/usnistgov/oscal-tools/tree/c4ca4c87aed225ee4be1f89ae410193d796cc485/xslt/publish/generic-preview

FedRAMP/10x teams have a lot of complex XSLT transforms, like our CIS/CRM transform WIP code. Might not be 100% what you are looking for, just FYI/FYE.

https://github.com/18F/fedramp-automation/pull/199/files

[GaryGapinski]

The following is a bit simpler than this transform (which produces HTML). The result is not quite a single text element but illustrates how such might be achieved. Input to the transform is this.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    exclude-result-prefixes="oscal"
    expand-text="true"
    version="3.0"
    xmlns:oscal="http://csrc.nist.gov/ns/oscal/1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xpath-default-namespace="http://csrc.nist.gov/ns/oscal/1.0">
    <xsl:output
        indent="true"
        method="xml" />
    <xsl:mode
        on-no-match="shallow-skip" />
    <xsl:template
        match="/">
        <statements>
            <xsl:apply-templates />
        </statements>
    </xsl:template>
    <xsl:template
        match="part[@name = 'statement']">
        <statement>
            <xsl:attribute
                name="id"
                select="@id" />
            <xsl:apply-templates
                mode="statement" />
        </statement>
    </xsl:template>
    <xsl:template
        match="insert"
        mode="statement">
        <xsl:text> [{@id-ref}] </xsl:text>
    </xsl:template>
    <xsl:template
        match="text()"
        mode="statement">
        <xsl:copy-of
            select="normalize-space()" />
    </xsl:template>
</xsl:stylesheet>

[wendellpiez]

NB the nice illustration by @GaryGapinski will produce output in no namespace. For OSCAL-namespaced output (even if not valid) add xmlns="http://csrc.nist.gov/ns/oscal/1.0" to the set of namespace declarations in the stylesheet element.

As for the general problem it's actually a good exercise for Day One of an XSLT course. Not difficult. But doing it gracefully requires some understanding, not just hacking.

[riknykn]

Thank you all @ohsh6o, @GaryGapinski and @wendellpiez! This was just what I was looking for.

[wendellpiez]

@riknykn you are welcome glad to help.

In the spirit of "beginner-level XSLT help" here's an even more detailed rundown.

By default, when not set to do otherwise, an XSLT processor copies the text of the entire input tree into the result. So if you have this XSLT you will get back a big data brick:

<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/>

Note I am using version 3.0 here. I am assuming XSLT version 2.0+ in what follows but the same will be true even in XSLT 1.0 with some adjustments for syntax.

Now this is not very useful since you say you only want statements. So there are two approaches to getting the statements only: remove everything else, or grab all the statements. Method 1 is usually preferable, but we are in a hurry so we pick Method 2:

<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xpath-default-namespace="http://csrc.nist.gov/ns/oscal/1.0" >
    
    <xsl:template match="/">
        <xsl:apply-templates select="//part[@name='statement']"/>
    </xsl:template>
    
</xsl:stylesheet>

This is great, but the statements are coming out by themselves. So maybe we add to each statement the label from its control:

<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xpath-default-namespace="http://csrc.nist.gov/ns/oscal/1.0" >
    
    <xsl:template match="/">
        <xsl:apply-templates select="//part[@name='statement']"/>
    </xsl:template>

    <xsl:template match="part">
        <xsl:text><!-- LF LF -->&#xA;&#xA;</xsl:text>
        <xsl:value-of select="../prop[@name]/@value"/>
        <xsl:text>: </xsl:text>
        <xsl:apply-templates/>
    </xsl:template>
    
</xsl:stylesheet>

And then since we are losing any trace of our insert elements inside the statements:

<xsl:template match="insert">
    <xsl:text>[insert </xsl:text>
    <xsl:value-of select="@type"/>
    <xsl:text>: </xsl:text>
    <xsl:value-of select="@id-ref"/>
    <xsl:text>]</xsl:text>
</xsl:template>

and to clean up whitespace (exploiting prior knowledge of the models) and indicate this is to produce plain text not markup (different serialization rules), at the top we can put:

<xsl:output method="text"/>
<xsl:strip-space elements="catalog group control param part"/>

So here is the entire thing again except in neater XSLT 3.0 text value template (TVT) syntax, and adding another template to handle the parts inside some of the statements:

<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xpath-default-namespace="http://csrc.nist.gov/ns/oscal/1.0" >
    
    <xsl:output method="text"/>
    <xsl:strip-space elements="catalog group control part"/>
    
    <xsl:template match="/">
        <xsl:apply-templates select="//part[@name='statement']"/>
    </xsl:template>

    <xsl:template match="part">
        <xsl:text expand-text="true">&#xA;&#xA; { ../prop[@name='label']/@value }: </xsl:text>
        <xsl:apply-templates/>
    </xsl:template>

    <xsl:template match="part[@name='statement']//part">
        <xsl:text expand-text="true">&#xA; { child::prop[@name='label']/@value }: </xsl:text>
        <xsl:apply-templates/>
    </xsl:template>
    
    <xsl:template match="insert" expand-text="true">[insert { @type }: { @id-ref }]</xsl:template>
    
</xsl:stylesheet>

The biggest difference between this and @GaryGapinski 's stylesheet is that his produces XML while this produces plain text.

However, it is their similarities that you should find more instructive. Both XSLTs rely on template matching as well as XPath to get the work done. So while his templates contain tagging for the XML in the result, the templates here have only instructions to write characters (plain text) -- or continue the template traversal to find more data (xsl:apply-templates).

[wendellpiez]

I should add, by "readable text" here I am assuming .txt. HTML or XML as @GaryGapinski shows will be similar in most important respects.