How should related filtering issues be consolidated?

[jyjeanne]

Hi,

I realize I opened several related issues in a short period of time, which may have created unnecessary noise.

I used AI tools mainly to help structure and organize the reports, but the behaviors themselves were manually investigated and verified before submission.

I’m currently revisiting each issue to add smaller reproduction cases, clearer expected behavior, and additional technical details where needed.

If some of these reports should be consolidated into fewer tracking issues, I’m happy to reorganize them accordingly.

Related issues:

• Hierarchical filtering: child include/flag does not propagate upward to unspecified parent #4769
• Hierarchical filtering: child explicit include drops inherited parent flag action #4768
• Hierarchical filtering: child explicit exclude not applied when parent has flag action #4767
• Hierarchical filtering: child explicit exclude not applied when parent has flag action #4767

[jelovirt]

If some of those issues are duplicates of each other, close the duplicates. Small reproduction cases are good. Also, each issue should be independent, so not reference the other issues for context.

[jyjeanne]

@jelovirt Here is what I have done to follow your recommendations:

Issues reorganized:

#4767 (Case 3) — Closed. After testing with DITA-OT 4.4.0, the described behavior does not reproduce. DITA-OT correctly applies the child exclude rule over the parent flag. I've posted the detailed test results as a comment before closing.

#4769 (Case 1) — Updated with a standalone minimal reproduction case (repro-case1/ folder). Cross-references to other issues removed. Test results confirming both the missing diagnostic warning and the incorrect filtering outcome are posted as a comment.

#4768 (Case 4) — Updated with a standalone minimal reproduction case (repro-case4/ folder). Cross-references removed. I also added a transparency note: the DITA 1.3 §5.2.4 normative passage specifically requiring flag inheritance for explicitly-included child values was not found verbatim in the OASIS documents. If the behavior is not explicitly mandated, please let me know whether to reclassify this as a spec enhancement request.

#4774 (Case 6) — created with a standalone minimal reproduction case (repro-case6/ folder) covering both the redhat=include and redhat=flag upward propagation variants. Cross-references removed. Oxygen XML Editor 28.0 is noted as conformant for this case, making this a DITA-OT–specific defect.

Dataset structure (same pattern in all repro cases):

repro-caseN/
├── subjectScheme.ditamap ← platformKey → linux → redhat (wrapper key structure)
├── topic.dita ← 3 paragraphs: generic, linux, redhat
├── test.ditamap ← root map
├── caseN.ditaval ← minimal DITAVAL for this specific scenario
└── README.md ← expected vs. actual output
All datasets were validated against DITA-OT 4.4.0 installed at C:\dita-ot\dita-ot-4.4. The README.md in each folder contains the exact HTML output excerpt confirming the bug.

Please let me know if any further clarification is needed.