How to handle profile resolution title addition?

[bradh]

The profile resolution spec for Instance metadata (3.4) includes:

<title>{ profile title} RESOLUTION</title>
<last-modified>{ resolution date stamp }</last-modified>
<prop name="catalog-title">{ imported catalog title }</prop>
<prop name="catalog-title">{ imported catalog title }</prop>

Leaving aside the last-modified part which I'll address in a follow-up question, how should I add in title? If its a simple string, its easy - just append. However the content of title is markup-line, which could contain various formatting (em, b, code etc), or parameters. That could look a bit weird, or even broken, depending on where you choose to drop the "RESOLUTION" part.

What logic should apply for complex profile titles?

[wendellpiez]

I think I need to see an example of where it would be weird. The intent was to append the string " RESOLUTION" always at the end, after and outside any inline markup.

The specification of how/whether to munge the profile title is certainly up for discussion. FWIW the reason title permits markup is to support (very) rare cases. One would not expect a parameter insertion into a title; indeed I would not blame a process for flagging that as an error.

[bradh]

I was thinking something like

<title>The <i>best profile</i></title>

Should that be:
<title>The <i>best profile</i> RESOLUTION</title>
<title>The <i>best profile RESOLUTION</i></title>

I think either is reasonable, but that makes testing a little harder.

What about if it is:
<title><b>Official Profile</b></title>

If title isn't really expected to have markup, maybe it should be simplified?

[david-waltermire]

@wendellpiez and @bradh I don't like the idea of changing the profile title. I believe it should be preserved as-is.

[wendellpiez]

That's fine. We can use this Issue to track a work item to revise the spec accordingly.

[brian-ruf]

@david-waltermire-nist @bradh @wendellpiez, while I agree with Dave's position as a recommended practice to avoid, I also feel this should be at the discretion of the tool developer.

That said, I think it is important to provide both a machine-readable and human-readable way to know when working with a resolved profile vs. an actual catalog. I suspect that is the underlying goal for @bradh as well.

At a minimum, a metadata prop could exist with the @name="resolved-profile" (possibly with a requirement to explicitly set the value to "yes", or just the existence of this prop could default to "yes" unless there is an explicit "no")

For FedRAMP, we added a prop @name="marking" for document sensitivity marking. (I'm going to pitch for this to be included in our metadata upgrade). Perhaps something similar or identical could be used with a value of "RESOLVED PROFILE" to be displayed in proximity to the title.

[wendellpiez]

@david-waltermire-nist @bradh @brianrufgsa I like this idea okay (using property addition instead of title munging). It is consistent with what else we are doing. The title should be whatever reasonable and informed users downstream expect for the title....

It seems reasonable to aim for a set of rules that is unambiguous enough that, if two different resolutions by two conformant tools cannot be guaranteed to be the same, at least their variances are limited to what is predictable, such as the different timestamp (a feature not a bug). But no variances is better; and indicators that an OSCAL catalog was produced from a profile, etc. could be the same for everyone.

If we want to stipulate that a tool can also "brand" or otherwise enhance a resolution by amending the metadata in other ways (which they would inevitably do differently), we should also say how and where this can be done. Maybe more properties?

<prop name="resolution-stamp">Resolved by software X from Vendor Y</prop>

[wendellpiez]

Bringing this Issue into #1076 and #1086 so we can address and close. We need to add appropriate unit tests to profile metadata handling in resolution, reflecting current spec in light of any further discussion.

[david-waltermire]

The current profile resolution specification is silent on what to use as the title. This will result is variability between implementations. For example, liboscal-java and XSLT implementations uses the profile title as-is. Other implementations are free to do as that want.

After reading this discussion there is no strong demand to be more specific about title handling in the profile specification. We will close this and wait for a time where there are stronger opinions.