Meeting minutes 2020 05 07

Attendance: Robert Anderson, Lief Erickson, Rob Richter, Radu Coravu, Bill Burns, Roger Sheen, George Bina, Jarno Elovirta, Frank Wegmann, John Pashley

Item 1: Any updates about prior releases?

Project board for 3.5.1: https://github.com/orgs/dita-ot/projects/22

Lightweight DITA plugin has an issue with markdown output, need to fix in 3.5.1. Did not have an automated test in place for this external plugin. Our automated E2E test is running to verify each native transform type runs to completion, but it's not running against transform types installed by the Dist build from external plugins. Should add E2E test for these - perhaps only run against release and hot fix branches?

If we had a more strict API, we could do something like Rust ... every 6 weeks when it releases, it goes through every package it can find and try to compile. Hard for us because even going thru every plugin in the registry, we don't know what test files to use to test schemas, for example. Could add ability to provide test files / scripts / project files ... gets complicated with dependencies ... could be done on someone's fork rather than automated on every commit by everyone.

That plugin needs to be updated to use <ditafileset> instead of the older list files.

Outcomes:

• Need to automate test of all plugins that we bundle
• Consider a way to better automate testing of all found / known plugins

Other issue: Jason Fox has a new issue, relative file paths failing for PDF builds, needs investigation.

Plan for 3.5.1 hot fix by our next contributor call at start of June.

Item 2: DITA-OT 3.6 or 4.0 Development status and updates

Project board for next release: https://github.com/orgs/dita-ot/projects/21

Jarno continues working on in-memory transformations. In order to make this work for preprocessing, chunking has to be rewritten. That's a problem. Can also consider adding bit-streams to in-memory transforms; when you add something to cache, it's either Saxon tree, DOM, or byte stream. This would allow in-mem transform to accept different inputs, serialize them, and would mean we don't need to rewrite chunking. Interestin switching over to Saxon's API, we're able to use in quite a few places. Did an experiment: create wrapper around DOM interface and make it read-only, throw an exception when you try to modify it. We have a few places where we read in DOM and don't modify, just serialize back; those are good candidates to use Saxon tree model, which is more efficient and nicer to work with than DOM.

Related: considerations about taking multiple input files. Probably not a lot of people doing this yet, if you were taking in lots of input files to produce one output file, what would you expect?

Basically: for all the years of DITA / DITA-OT, a build starts with one start file. Why? If you could specify several, what could you do? How do you split or combine?

Goal of next release: looking for things to do with DITA 2.0. The pandemic is wreaking havoc on everyone's schedule so not sure how far along it will be this summer - but goal is to track it.

For next major release - general clean up and deprecation. Roger has noted a lot of CSS styles explicitly set in the HTML output which is a good candidate for simple cleanup.

As often, tracking the ability to add CSS based PDF, but as always, depends on availability of tools to help with that.

Radu: would like as usual to address backlog of defects, as many as possible.

Frank: any progress on lightweight DITA support? Does not seem to have changed much. Little progress on / change to HDITA, versus the xml and markdown versions - most of the LwDITA attention from both authors and vendors seems to be on MDITA and XDITA.

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

TOC rearranged a bit for 3.5, largely based on last month's call; got input from Leif and Shane, thanks to both. As usual, when different people look at the TOC they want different things, so we can't make it Just Right for everyone. General principle: differentiate between "how to use plugins" and "how to create plugins", so that if you want to use existing stuff but not develop, you can find it more easily; if you want to develop, also dedicated spot for that.

Making some progress on testing docs with Vale. Lot of errors for things flagged as spelling mistakes (for our parameter names). Could add exceptions for those, but ... there really are a lot, many are generated today but don't really want to generate a Vale exception list. Vale testing is entirely based on HTML output (it doesn't read the DITA), so things that might obviously be code-like in DITA are getting tested because there is no equivalent HTML markup for them. Roger approached them - the next release will have class-based testing, which would allow us to easily test these things.

Item 4: DITA-OT Day

On pandemic hold

Item 5: Other topics

Next meeting expected June 4.

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.