Aligining the definitions for title and p elements (or clarifying the difference?) about schematron-enhancement-proposals HOT 3 OPEN

<dir> can be mapped to Unicode's directional override characters, so <title> is effectively text with syntactic sugar for directionality overrides (except that the syntactic sugar allows foreign elements).

A HTML <title> can also contain only text.

I'm not advocating either way, but an argument for a simple <title> is that a styled title might lose meaning or be confusing if it ends up somewhere where only text is allowed, such as the banner of a window or the metadata of a PDF report.

from schematron-enhancement-proposals.

an argument for a simple <title> is that a styled title might lose meaning or be confusing if it ends up somewhere where only text is allowed, such as the banner of a window or the metadata of a PDF report.

True. However, other text standards, such as DocBook, simply allow mixed text, with all its markup elements, everywhere where text can be, so also in <title> elements. I think this consistency is preferable above deciding upfront what content developers should or should not do.

from schematron-enhancement-proposals.

Are titles different from paragraphs and divs? Definitely yes!

We should consider the Gherkin BDD language, which is used to generate stubs for the popular Cucumber BDD Unit Test runner (for Ruby, JavaScript, Java, etc). It is VERY commonly used and highly regarded. It is entirely based on automatically converting titles into programming language identifiers (e.g. function names).

Gherkin's design has evolved to have many of the same language features as Schematron: a separation between expression of scenario in native language and implementation in code (e.g. as sch:assert/@test does), relatively flat simple structure (Feature/Rule/Scenario/Step is akin to schema/pattern/rule/assert), variables, macros, a way to avoid context recomputation (in Schematron this is the sch:rule chain, in Gherkin it is the Background feature), and so on.

And guess what?, those top three levels (Feature, Rule, Scenario) all require a title (which they munge into a name token by substituting " " with "_" for example) and allow free-text comments as paragraphs after the title, to explain things. (And which are distinct from stripped #comments that are ephemeral.) Just like Scematron.

So we can imagine an application that takes a Schematron schema and transforms it into, say, idomatic JUnit Unit Tests for Java: and uses the (munged) titles as function names for literate code (or ids otherwise). It would be good if this were just a matter of taking the simple value of the sch:title/sch:p.

But if the foreign element had text, is is supposed to be displayed as part of the title or not? For example

<sch:pattern id="p2022">
sch:titleDrug Interaction Test Rules as at <external:date date="2022-02-20">202e
<external:note id="f1">Provenance Note: these rules were approved by Committee X on 2022-01-0-31
and made under Code 7 of the Pharmacy/Illuminat Co-Prosperity Sphere Guidelines.</external:note></sch:title>

We have two foreign elements: one does belong to the display text of the title (which would be munged to make the identifier) but the other does not. We don't want to ignore the date (because there may be other patterns with the same naming convention for other years; and we don't want to put in the full external:note because of size and that it may change without requiring a regeneration of the code; so there is no failsafe general policy.

If you wanted to allow foreign elements with no text value, that is no problem for this, of course. But if you allow foreign elements, you give up that implementation technique, which is unnecessary.

Now I do not know of anyone who has implemented Schematron-to-JUnit (etc) with this name munging. But do we have any actual report that anyone has had a problem with an sch:title not allowing foreign elements?

If there is no actual problem reported, and the feature supports a particular COMMON implementation technique in the testing/validation sector, then it is better to keep it.

As for DOCBOOK, I see an application that converts a Schematron schema to DOCBOOK (or any other rich text), but I don't see that there is any requirement that DOCBOOK be converted into Schematron code (is there?) So I think there is an argument that Schematron rich text should be able to drive DOCBOOK or DITA well, but not that it should losslessly round-trip.

from schematron-enhancement-proposals.