Print DSL expressiveness: negated row filters and placeholder fallback (if/else)

[delchev]

Two expressiveness gaps in the document-template (print) DSL, surfaced by real templates hand-authored over the generated scaffolds. Filed as one discussion because they are both "the binder cannot express a common template condition" and should probably land as one small grammar increment.

1. Negated row filter

<table>/<for> row selection today: filter= keeps rows whose named source value is truthy, and match= narrows to rows whose value equals a literal. "All rows EXCEPT ..." is inexpressible.

Real exposure: a document whose line items mix customer-facing and internal rows (an internal-note flag on the item) prints the internal rows on the customer-facing document - there is no way to say internal != 1.

Options, roughly in order of preference:

• matchNot="<literal>" (and/or filterNot="<key>") - symmetric with the existing attributes, one-line semantics in DataBinder.
• A general comparison grammar in match (match="internal != 1") - more power, but starts a mini expression language the DSL has deliberately avoided.
• Feeder-side exclusion (the generated feeder omits flagged rows) - no DSL change, but it bakes ONE document's policy into the shared feeder; two templates over the same document (customer copy + internal copy) then cannot differ.

2. Placeholder fallback / else branch

There is no {{a || b}} and <if> has no <else>: an empty optional field prints blank where the base value should degrade in. The canonical case is multilingual/display names - "print the trade name, fall back to the legal name" - or "delivery address, else the billing address".

Options:

• {{a || b}} fallback chains in the placeholder grammar (first non-blank wins) - smallest authoring surface, easy in DataBinder.resolve.
• <else> inside <if> - more verbose but composes with block content, not just single values.
• Both (they answer different shapes: value fallback vs block alternative).

Related, already addressed separately

The third defect found in the same review - the scaffold referencing keys the feeder never puts (dead {{document.Id}} / unlabeled back-reference maps) - is a generator-contract bug, not a DSL gap: fixed in #6503 / PR #6504 (shared label resolution + a scaffold ⊆ feeder-contract test).

The DSL v1 limits are documented in modules/parsers/document (README) and were deliberate; this asks whether these two are now worth their grammar cost, given they blocked real templates.