Meeting minutes 2014 04 08

Attendance: Robert, George, Jarno, Eliot, Kris

Item 1: 1.8 release status

Have 5 fixes out there that could be released as 1.8.5. Could release but nothing urgent. Eero has been looking through bug reports to find old items that could be closed; sending some pull requests but haven't merged them all back into 1.8.5. But, don't want to break anything so do not want to include major items.

DITA-OT 2.0

Jarno has not had a lot of time lately.

For latest code, removed old FrameMaker syntax for index terms (has been deprecated / off by default for years). Same function can be achieved with a pre-process step to convert to proper markup.

New issue/feature: whether to change minimum Java version to 7. Jarno and Radu chatting in the issue. 1.6 has been end-of-life for a while so would be good to upgrade; also, Java 8 is already out. If we are going to update Java version, would be good to do now (rather than in 2.1 or 2.2). But, Java 7 doesn't have a lot of features we need/want to use, so could live with 6. Main reason to move is to keep up with supported releases. From Radu's comments, OS-X is holding us back - it ships with Java 6. Jarno notes: Windows doesn't ship with any Java, so could make Mac users install Java 7, just like Win users. Eliot points out: reason I don't have a mac is so I don't have to update Java. (Lots of discussion). Jarno suggests: try going to 7 and see how it goes in the milestone packages; if it's a problem, go back. Try to stick with Java 6 syntax for now in case of issues. And if you don't want to use the command line tool, get a tool (such as Oxygen) that can run the OT build for you.

Jarno started working on branch filtering for 2.0, then got sucked into the specification when working on it. Want to wait for spec to clear up a bit for that. Still not sure that key scopes can be implemented in combination with branch filter. Next DITA 1.3 item to work on is likely key scopes. Robert and Kris both think that is best - most likely to result in comments / clarifications to spec. Jarno already added key scope name validation, but that part was easy.

General change in 2.0 that Robert / Jarno have discussed: implement map merge earlier? Right now takes place after conref / keyref processing. But processing could be simplified in many spots if you did it earlier, as long as you keep info about where sub-map came from (have to know map boundaries for proper key resolution, for example). May do this before working on key scopes. Would need to do something like - add a specialized topicgroup as a wrapper around the submap. Robert likes this idea of the specialized group. Can add a switch at end of processing to keep it or strip it out (strip gets output more like today).

Reminder: particularly for 1.3 features, the goal of DITA-OT 2.0 is to get it right / comply with spec / have good logical code. Over time can optimize for performance.

Jarno asks: are there any features that are redundant and should be thrown away? For example, the Framemaker syntax in index entries? Eliot wonders about docbook plug-in, legacy PDF transform... how many plug-ins are sufficiently maintained to be worth shipping. Jarno: already moved most of the (mostly) unsupported plug-ins into a separate repository. In 1.8 we ship legacy PDF, but it is not in 2.0 - has no owner and don't expect one.

Another example: RTF code. Frank made a lot of updates, and validating them with Word. Output is improved for Word, but now cannot be used by some other RTF readers. May need to break it into two plug-ins (rtf, and wordrtf).

Eliot thinking about a place to store lightly-supported or use-at-your-own-risk plug-ins. A single place people can go to get such things. Haven't had time to pursue. Jarno points out: new client tool now supports installing plug-ins when given a URL. Could be updated to say "install PDF", toolkit gets list of supported plug-ins from someplace, and fetch the PDF plug-in. But, requires maintenance, somebody to update.

Similar discussion around eclipsecontent transform type. Lots of people using today and want the function, but no reason to tie it to Eclipse - would prefer a normalized DITA transtype, and if you really want the Eclipse function, go get it from ext-plugins or similar.