Meeting minutes 2020 02 06

Attendance: Robert Anderson, Bill Gamboa, Radu Coravu, Frank Wegmann, Jarno Elovirta, John Pashley, Rob Richter

Item 1: Any updates about prior releases?

Status on 3.4.1 - Robert needs to get back to the open / unresolved issue in the patch.

Item 2: DITA-OT 3.5 Development status and updates

3.5 project board: https://github.com/orgs/dita-ot/projects/18

CLI changes done but need input from docs team about how to handle that.

Some of Jarno's plans for Abstract Storage in next release are getting held up by chunking. It is fragile and breaks easily. We have a lot of test cases for it - uncertain how many test truly useful conditions. DITA 2.0 abandons several of the unused / unimportant conditions. Overall split/merge process is not that technically complicated, but we do it all at once and ... it's fragile. We could cherry pick some of the Abstract Storage work and ship in next release; but that would still be invisible to end users so doesn't show up as a new feature.

Looking for DITA 2.0 items that might be interesting, and could be doable this month:

• Change from @domains to @specializations, new values for @chunk could be handled with a filter that converts to old and continues with 1.3 processing
• New support for @outputclass in DITAVAL
• Could ship latest grammar files
• New include element? Not sure how easy this would be, to generalize from current coderef - the new element can include text or XML.
• New index models

Fairly simple processing changes to support modified class attributes:

• Support changed specialization base for image map
• Allow nested steps

Would be nice if OASIS github could auto-generate and upload a plugin of doctypes. Even if they don't, we could find a way to generate it.

Radu added several issues lately for discussion:

• Issue with project files. Specify output folder that is relative. Expect it to be relative to the DITAMAP but it ends up relative to the Java program (created in DITA-OT folder). Jarno: way it is designed, it's supposed to work similar to what would happen if you specify the same arguments on the CLI. If you specify a relative path on CLI, path will be relative to that location. If you specify -o on CLI and an output directory in the project file, it becomes relative to the -o location. Seems like path of least astonishment. Should probably continue discussion in the issue - what would make the most sense. Radu's goal: make the project file portable, so that I don't have to specify absolute location after moving. https://github.com/dita-ot/dita-ot/issues/3432
• Other issue about XEP indexing - wasn't updated to go with changes made some years ago, so index output does not work. Stylesheet should just need minor changes. Radu has already made them, can open pull request. https://github.com/dita-ot/dita-ot/issues/3447
• Had a request for supporting @rotate attribute in HTML. Need to pass it somehow so that CSS can then rotate. https://github.com/dita-ot/dita-ot/issues/3448
• Need to update license file for ICU4J - they redid their license. Best to fix in 3.4.1 and if that doesn't get released in the next week, cherry pick it into develop https://github.com/dita-ot/dita-ot/issues/3444

Item 3: Doc updates and plans, update on documentation call

Roger and Lief both out; need review / input on how docs should handle CLI changes.

Item 4: DITA-OT Day?

Radu notes that he's already gotten one question from a past attendee about whether / when it will happen next.

Item 5: Other topics

...

Item 6: Backlog discussion

Project boards: Project boards: https://github.com/orgs/dita-ot/projects/

Time to go through pull requests, issues tracker, determine how to handle open issues.