<description>s are simultaneously required and may have void content.

[GaryGapinski]

The <description> element (e.g.), while having a cardinality of {1.1}, allows void content due to the definition of markupMultilineType.

Is this intentional? <description /> is thus allowed.

(This observation is of course viewed from the prospect of XML Schema.)

[aj-stein-nist]

Is this intentional? <description /> is thus allowed.

I don't know if it was/is, but I am part of the "explicit is better than implicit" camp. :-)

[wendellpiez]

Due to the nature of markup-multiline and markup-line, and the need to keep them aligned with both Markdown and a markup vocabulary, it is really not practical nor advisable (in my view) to try to express a requirement for "meaningful data content" in these places (for example, to exclude whitespace-only). (Same thing applies to title, which is markup-line.) But the lack of support in a (schema) content model doesn't mean there is nothing that can be done.

There are ways to guard against it nonetheless, for example we could add support via a constraint definition applying to description (or title). We have a matches test for this.

However, at some point this inevitably becomes a data quality issue, not a validation issue. If we forbid "" (either no content or whitespace-only) then those who wish to evade the error will input "TODO" or some such. Then we get "TODO" all over our data instead of empties. Arguably that is more informative, but as far as actionability is concerned (what to do), it amounts to the same thing.

At the same time, a Schematron precheck that says "of 110 description elements in this SSP, 90 have no content" offers useful info. The same precheck might also check for boilerplate or other kinds of evasions ("of 110 description elements, 90 have the same value, "TODO") - the kinds of things no schema is going to know how to look for.

[GaryGapinski]

This depends on how the occasional schema (cardinality of {1,1}) requirement of "a description must be present" is interpreted. "Yes! We Have No Bananas" is currently accepted. The cardinality of {0,1} variant is "We might but need not assert that we have or have not bananas".

That which is not forbidden is allowed.

[aj-stein-nist]

That which is not forbidden is allowed.

I suspect @GaryGapinski might have happened upon the new unofficial slogan of OSCALites everywhere, novice and expert alike. :-)

[wendellpiez]

I would be fine with an optional description, indeed I argued it should be optional on exactly these grounds (to require it invites abuse). But I was overruled by those who insisted on "a description must be present" (even when said description contained nothing or nothing meaningful - indeed this is always possible), who had their stated reasons.

What I'm not in favor of is revisiting markup-multiline in view of this (which is what I believe is implied in requiring description to have contents) mainly because of the rather onerous implications of trying to define a Markdown syntax that requires text content, but presumably will not be valid on a line like \n### ** (a line break followed by three hashes and two stars) since there is "no text there" (how a JSON validator should approach that I don't know - parse the Markdown, then query the resulting HTML?) - to say nothing of its XML equivalent (a content model in which elements are optional but their text contents are required?) - etc.

Making description optional would be a backward-incompatible change for v2, if you can convince us - meanwhile, use your Schematron.

"That which is not forbidden is allowed" is a poor juridical principle to apply to a class of 1st Graders. And games that rely on it (Diplomacy comes to mind, or maybe ice hockey?) are particularly brutal.