Which entities of the YAML input are actually being validated?

[wlatendresse]

YAML validation when and where?

I'm just wondering which parts of the YAML project configuration are currently being validated (there are some open issues for YAML validation: #11560, #11033, ... ).

The background to the question is quite simple: According to Quarto docs book output, it is valid to use "scrbook" or "scrreport" for "documentclass" when generating PDFs . Komascript, however, knows more definitions (see Pandoc documentation.

The real background is of course the fact that PDF generation fails in that case. But is this an issue? (In my opinion it is.)

For example, using "scrartcl" at this point (which is a valid template), the generation of the PDF will simply result in an Tex error, but Quarto does not point out anywhere that the value might be invalid.

[cookesan]

I think the key distinction here is schema validation vs semantic render validation.

In the current schema, documentclass is a PDF-tagged field, but its schema is still string. The listed classes (scrartcl, scrbook, scrreprt, scrlttr2, article, book, report, memoir) are completions, not an enum. So YAML validation can validate that the field is a string and appears in a place where PDF options are allowed, but it will not reject another string as an unsupported LaTeX class.

There are two relevant validation paths:

• document front matter is validated against getFrontMatterSchema() unless that YAML sets validate-yaml: false
• _quarto.yml project config is read against getProjectConfigSchema(), which combines project fields, execute/format fields, and the front-matter schema

After that, many format values are passed through to Pandoc/LaTeX. documentclass is in that category because the schema declares it as a string. So I would read this as either a schema-tightening request, if Quarto wants to reject classes outside the listed set, or a separate render-time diagnostic request, not as evidence that YAML validation is not running at all.

[wlatendresse]

I think the key distinction here is schema validation vs semantic render validation.

In the current schema, documentclass is a PDF-tagged field, but its schema is still string. The listed classes (scrartcl, scrbook, scrreprt, scrlttr2, article, book, report, memoir) are completions, not an enum. So YAML validation can validate that the field is a string and appears in a place where PDF options are allowed, but it will not reject another string as an unsupported LaTeX class.

Thanks for those pointers.

It may be true that the values for "documentclass" (and presumably other identifiers) in the YAML files are only intended to represent and represent unknown strings.

However, the question then arises as to whether a validation regarding the content should not take place after that at the latest (which is definitely not happening at the moment, as far as I can judge after a first look at the relevant sources).

Several approaches are conceivable:

• A number of ready-made files that also serve as documentation and templates for real projects.
• A generator that generates configurations that are then used to run tests against.
• A combination of the above and probably other possibilities.

Because at the moment not all of the above values work in v1.9.37 and "documentclass" represents a relatively top-level entity, there are probably other combinations of other configurations that do not allow the program to generate it's output.

A resulting question is: "Shouldn't all the above-mentioned possibilities for "documentclass" actually work during generation of documents, regardless of the format (or at least warn about invalid combinations before any attempt to generate documents that will fail anyway)?

After that, many format values are passed through to Pandoc/LaTeX. documentclass is in that category because the schema declares it as a string. So I would read this as either a schema-tightening request, if Quarto wants to reject classes outside the listed set, or a separate render-time diagnostic request, not as evidence that YAML validation is not running at all.

One of the many reasons I've always been a fan of the strictness found in XML schema (fail early). But that's a different topic.