Meeting minutes 2018 12 06

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

Item 1: Any updates about prior releases?

3.2 project board closed: https://github.com/orgs/dita-ot/projects/5

3.2.1 tag just pushed -- will build and ship today, Roger to create the Homebrew update.

Item 2: DITA-OT 3.3 Development status and updates

3.3 project board: https://github.com/orgs/dita-ot/projects/9

Discussion: should we release 3.3 a bit earlier? For the last couple years we've had a early summer release, which gives a short release cycle leading up to DITA-OT Day. Might be good to reverse that - have the short cycle earlier and give time for more significant function in the fall release.

After discussion - tentative plan is to have DITA-OT 3.3 around end of February. Will discuss again in Jan and Feb contributor calls to ensure that anything we've planned will be able to go in so that we have some features in the release.

Robert working on a couple small items - PDF table entry rotation, HTML support for hazard domain (just bring to parity with PDF, not planning more at this point).

Jarno working on change to move XSL files from root DITA-OT directory to plugins/org.dita.base/xsl. Should have been there long ago for consistency with [everything]. Last time we considered was some years ago and we were nervous about breaking hard-coded relative paths to imported XSL. At this point the plugin: syntax has been around for a long time and is the preferred way to reference, and makes these moves invisible. But this does mean it could break really old plugins - will need to change the import/include lines. May be a good idea for the integration process to flag these when it finds them - "You need to fix this" and even automatically fix if it can.

Jarno investigating DITA-OT workspace idea: instead of generating files in install directory (with integration / plugin install), those custom files go in the app directory in the workspace. Should be completely invisible change for end users; ultimate goal is to enable DITA-OT to be a bunch of JAR files without needing to rewrite all the dynamic files within DITA-OT itself.

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

Several new items open without a lot of time to make progress yet.

Radu asked for more examples of extensions -- good idea but probably needs to be handled consistently across extension points. Now that we have the registry, could even refer to some examples in the registry (though we have tried to limit external dependencies in the docs to this point).

Docs and lightweight DITA: it depends on LwDITA support, which is only added during the distribution build; means that if you try to build the docs with a clone of DITA-OT it won't work. Probably OK but could be a surprise if anybody runs into it. Could either take those files out, or update instructions (you have to use a dist build or create a dist build if you want to build the docs). Reason the files are there are largely to show it works (docs try to test most major features) -- something to point to. Roger inclined to go with updating the readme.

Item 4: DITA-OT Day 2018

https://www.oxygenxml.com/events/2018/dita-ot_day.html

Thanks all for making it happen. Robert particularly appreciated having so many other people talk about what they are doing. Did get about 20 survey responses about what people liked, didn't like, or would like to see more of in another one.

Item 5: Other topics

When do we start on DITA 2.0? Some items available but mostly minor ones. Robert has finally completed a draft of the big overhaul to chunking; waiting on feedback from reviewers now and then will go to full TC for discussion. Will require a new processing module - the old one should not be updated.

The new proposal defines only 2 tokens to "split" or "combine". Those are basically the same as today's "by-topic" and "to-content"; all other tokens are dropped, and the ability to combine tokens is dropped. Robert had hoped that the new module could just become the default and support those tokens interchangeably. Jarno mentioned automatically detecting 2.0 content and running the new module (and likely any other new feature modules) when the input is 2.0. Would like to add info to the job file to identify the DITA version of each document; keeping in mind that when people do adopt 2.0 (and maybe for a long time) many larger builds will be a mix of 2.0 and 1.x.

Question about how we will roll out 2.0 support - as a preview, or you need to do something special to test it? This is likely easier than with 1.3. With 1.2 and 1.3 documents used the same public identifiers, so we had to decide at some point to switch the default for all OT processing. With 2.0 the identifiers must change (otherwise we could break XML validation for any document not migrated). So, we can ship the latest 2.0 work and label it "preview"; once it is final we can remove the "preview" label but there is no real switch-over to plan around.

Item 6: Backlog discussion

Discussed using a bot to auto-close older issues. Planning to go ahead with that soon -- start the clock on older issues that will be closed later. Roger will look into it over the next few days.

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.