Meeting minutes 2021 04 01

Attendance: Robert Anderson, Jarno Elovirta, Radu Coravu, John Pashley, Greg Wait, Joe Williams, Lief Erickson, Frank Wegmann, John Kirkilis, Kris Eberlein, Bill Gamboa

Item 1: Any updates about prior releases?

Any patches planned or other concerns about 3.6?

Item 2: DITA-OT 3.Next Development status and updates

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

Jarno notes that on the xml.com Slack channel, they are talking about Saxon 11. We've talked about moving to Saxon 10, an implementation of XSLT 3.0, but our stuff is all 2.0. XSL changed so that if you use document() and that file doesn't exist, it throws an error that an XSL 3 stylesheet should catch (otherwise it aborts). One alternative is to use URI resolvers that can prevent the XSL failures, so that our stylesheets continue to work. Might be nice to do that, so we don't get too far behind on Saxon versions. The version we ship 9.9 does support XSLT 3 but the new versions are based on that.

Some progress on DITA 2.0 chunking but not a lot. Hoping we can ship some version of it in next release.

Item 3: Doc updates and plans

Still need to do some work to move away from Travis, to GitHub Actions.

Minor updates needed for Homebrew. Where they store things in the Cellar has changed slightly due to ARM processors.

Item 4: Jarno's Awesome PDF Plugin Updates

PDF plugin generator has been around for a while. Originally in Python, then JS running on server, then JS running in browser. Now it's rewritten in XSLT to try out Saxon JS. Able to convert generation code to XSLT and seems to work nicely. If someone wants to contribute, it might now be easier, because in XSLT.

Wild new update: you can use JSON file to set parameters. Running OT, it can generate stylesheets on the fly with your JSON input, and then that runs to build the PDF. When you run OT, you give it the input map, transtype like -f pdf, and then new argument to pass the template (path to that JSON file). The plugin generates the stylesheets on the fly, and then you get a PDF based on that.

Came partly out of discussion about other tools / formats like ASCIIDoc that come with similar configuration files.

So: should this plugin be shipped in OT, or should it go in the registry?

Few thoughts:

• Depends a bit on confidence level in how it works; if not high, registry first.
• How comprehensive is it? If only a subset of the features, might not be used as much. Answer: it has the full capabilities of the plugin generator.
• Not sure how many people know about or use the registry, certainly more likely to be noticed if in the bundle + in the release notes.

A few problems that have come up. What to do with support for Antenna House / RenderX? Jarno doesn't have a license for either so cannot test. We ship with FOP. If we bundle this plugin + bundle FOP then the tool should probably target FOP. Antenna House probably steers more customers to their PDF5 plugin. Implementation is already there for some specific items and won't be removed, but going forward, do we want to invest in features that only AH supports; probably not able to do that now. The basic stuff is common to all 3 anyway so focusing on the basic is probably the best approach.

PDF2 is rather opinionated, sets all kinds of things. This builds on top of PDF2. What should the output be if you don't set (for example) a font size for heading 1? Options:

• Use the PDF2 default
• Have this plugin set its own (configurable) default
• Throw an error When this same code is used in the UI version of the generator, it has a default for everything; there are no holes. So, it never defaults back to PDF2. But we don't want to force people to write 200 lines of JSON, setting every value. So, what to do? Defaults for PDF2 are not that pretty either, which is why so many people want to change them. Principle of least surprise seems to say, use PDF2 default.

One alternative suggested, could have the default be that it sets everything, but first entry in the JSON could alternately be "extends default PDF". Which suggests having configurations that extend other configurations which is likely a version 2 thing.

Could also update the UI to generate the JSON rather than a plugin...

Item 5: Other topics

Update on DITA 2.0: activity picking up in the last couple weeks, grammar files at OASIS now up to date with approved proposals. Question: they are still beta versions, if we update in DITA-OT distro, should that be in a hotfix or in develop?

They are technically backwards incompatible, though you would have to already have your own configured document type on top of 2.0; those would need to add the new alternate title domain.

Seems safe to update, given that this is clearly a pre-release version and can only impact documents using the DITA 2.0 beta.

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.