Meeting minutes 2015 01 13

Attendance: Robert, Roger, Jarno, George, Eliot, Shane

Item 1: 1.8.x release status

No current plans. Have a few items in the branch that are rather old. Could release if needed; others can build as needed.

DITA-OT 2.0 status and updates

2.0.1 patch release tagged. Packages not built yet (Jarno's missing a Windows machine). Need to clone master. If you have existing master, you have doc in main repo. But for 2.0.1 it's in sub-repo. May cause some issues. If you get issues switching branches, do a fresh clone.

No branch yet for 2.0.2.

DITA-OT 2.1 development

OASIS really pushing towards final spec in March - should have "final" language then, at least as reviewed by TC itself before public review. Easier to move forward on remaining DITA 1.3 items at that point.

Robert opened new issue about removing keyref processing from final XHTML code, adding @dita-ot:href to non-linking elements like phrases that get links from keyref. Should not be too complex. Jarno may grab this issue but if somebody gets there first. Changes should be in the Java code for keyref resolution. Haven't thought about keyword part - resolving text - may not want to do it for empty elements like abbreviated-form? Haven't fully thought out, if later rendition step expects empty element.

Side effect: could have a doc topic about "output of preprocess". Document the changes made, but more specifically the PIs and namespaced attributes/elements. Should at least open an issue with stuff we already know about. Update: Robert has opened https://github.com/dita-ot/docs/issues/17

Other 2.1 issue: Jarno has been working on Markdown parser integration, to use it as DITA input file (looking ahead to lightweight DITA / markdown integration). Reads in markdown, converts to DITA, remainder of processing goes as usual. Don't want it in core OT - doing it as plugin. While working on this, noticed that the way we let plugins integrate Java JAR code is rather broken. It's used by PDF2 - we give Ant a list of JAR files - when new tasks are created, you can use that list. Problem: Ant uses multiple class loaders, not always easy to get access to them, making this sort of a broken system. Docs currently say: configure your plugin like this to find the jar, but it doesn't really work in all situations. We currently have the "dita" command and the traditional batch calling-of-ant approach. OK with forcing those using the traditional approach to keep working as-is but "dita" command line should Just Work. Could fork ant launcher, but don't really want to do that. Could have dita.bat shell file become a template file - rewrite to insert list of JAR files from plugins. All other templates are XML so this would be new. Also considering - setting local environment variable that is used as local classpath. Haven't come up with any more elegant solutions.

Oxygen's way of running DITA-OT is sort of a third way. Launches new instance of JVM, call Ant there. Set JAR files using the -lib argument. Would be convenient if Oxygen could read the list of plugin JARs from somewhere. Also not sure how to handle that.

Eliot's comment: thinking having separate script file is probably the best approach.

Jarno: want to make sure we don't leave Oxygen behind (or something working in the same manner). Could generate the environment variable script but also generate an XML file that is easily readable by Oxygen or a CMS or whatever.

Other question: have a plugin that generates Microsoft Word XML output - output is similar to ODT, but no shared code. One requirement - everything split between blocks/inline elements. Blocks can't nest blocks, except for tables. Have a first step that breaks everything into blocks/inline - is that general enough to be part of OT as a useful building block? Eliot and Robert both think yes. It's also similar to the troff approach, which starts by converting DITA to a set of block/inline elements.

Doc updates and plans

Questions:

• Jarno and Roger worked together in Helsinki recently. Jarno updated website output to use latest bootstrap; makes page more responsive.
• Also fixed some things with the moved docs (moving to subrepository).
• Roger's focus now on refactoring, getting head around code for docs, cleaning up old docs / removing unreferenced files / removing outdated things. Want opinion on some things.
  • Have some content that is outdated, unreferenced, not published. For example, old DeveloperWorks articles and quick-start-guide. Should we keep them, since we're not maintaining them? Robert votes for removing. Roger thinking the same - if anybody wants them, check out old tag (hard to discover, but...)
  • Thinking about refactoring to make some things more transparent: simplify root level so that you just have root maps; move submaps into folders with their content; edit folder names to reflect content. For example, most of user guide is in "readme" folder, which no longer makes sense. But ... those links have been posted (for example, "readme" path shared on dita-users as part of announce note). Robert's preference: leave the paths alone for 2.0.x fixpacks, no churn for fix updates, but do all the renaming we want for 2.1.
• Roger noticed that "dita-ot.org" wasn't redirecting to "www.dita-ot.org". It was working in December. Robert needs to follow up.

Other topics

Eliot: been doing some migration of plugins from 1.8 to 2.0. Is there a list of code changes that would affect migration? Answer: Don't have dedicated topic about it. Would still like to see it. Release notes have some minimal info. If Eliot can keep a list of changes then we may be able to use that as a basis for the topic. Most things found so far are removed old (deprecated) templates. Updating PDF was more complex at times.

Eliot: can also report so far, haven't run into any cases with D4P where couldn't make the XSLT code work in both 1.8 and 2.0. For preprocess, that's not the case, some targets from 1.8 are not in 2.0.