Meeting minutes 2012 07 03

Attendance: Robert, Jarno, Kris, Eric, George, Radu, Mikhail, Frank, Eliot

Item 1: 1.6 Release follow-up

Release complete, uploaded last week. Code will remain available for fixes; when possible, defects should be checked in to 1.6 and 1.7. If any urgent defects are discovered, a patched version (1.6.1) can be released with all fixes added up to that point.

Item 2: 1.7 short term plans (Milestone 1)

• Robert: few specific items; may get started on the flagging issue. Also - integrate Kris's suggested message updates.
• Jarno: started collecting issues for 1.7 at github. Currently have 10 open, some big, some not. One other issue came up in dita-users, change how xref to tables / figures are rendered in PDF - likely create new issue for this. Will likely continue work on HTML5 output - should be working in milestone 1. By HTML5, don't mean fancy JS / Ajax interface - just mean valid HTML5 docs at this point.
• Eric: updates to Schemas based on feedback from dita-users and TC - push those into 1.6 as well. Take a peek at some items in defect list.
• Frank: Will be upgrading local install to 1.6 - may bring out some items that can contribute.
• Kris: Can contribute to docs
• Oxygen - would like to get to know project better, keep Relax NG branch up to date.

Item 3: 1.7 long term plans

Most of these are open in the issue tracker already:

• Relax NG implementation of DITA, Oxygen working on it - if we can get it in, would be great
• Extracting flag logic from XHTML - Robert working on initial designs in Milestone 1
• Request to get TOC into every HTML file - Jarno contemplating
• Related to previous - "webhelp" type output - discussing possibilities
• Duplicates attribute in related links not supported - would like to implement
• Would like to make globalization independent of transform type - have two very different methods (PDF and Others). Would like to have single syntax
• New option to flatten directory structure - Jarno would implement as part of pre-process, but could do elsewhere.
• Other cleanup work - refactor pre-process code to use Sax filters rather than writing XML using Java writers
• Have been thinking for a while - would like to be able to define input files using URI (URL in the beginning) - specify an address in a CMS, OT could grab over HTTP rather than having to download to local file system prior to build. Componize has been doing something similar - main challenge has been Java code. Approach has been - have not touched the Java code - but before calling Java the file is saved to local temp, run Java, retrieve; or, have re-implemented Java code in XSLT. Jarno has considered; would like to make it work so that people could choose Java (SAX processing) or XSLT, just glue different implementations in place. Can change default if one proves better than the other (performance, cleaner code, whatever). Note that some of the issues with the file list, ties to the file system, are caused by Ant; Componize uses XPROC instead, Jarno has played around with Python. Another alternative is Eliot's map-driven process; currently done using the output of pre-process, but could manage the entire pre-process as one unified XSLT. Jarno points out - would still require Java for some cases (reading an image size, working with 100K documents at a time requires extensions to manage memory). Would like to write the code in a way to make it easier to swap out implementations.
• Pre-process reads files twice (generate lists, debug-and-filter); would like to read only once, but code is messy so has been difficult. List generation is needed prior to debug-and-filter. So, quite a big effort.
• XSLT 2.0: still out of equation? Have tried to allow 1.0 in the past so that we could in theory still use Xalan. Jarno has been working to make sure Saxon's latest free edition works with the code, though he encourages everybody to buy a license for the full version. One option: develop the code in pre-process in XSLT 2.0 so that we could have alternate builds - one for Xalan, one for XSLT 2.0. But would need to go through all stylesheets and verify that they actually work as XSLT 2.0. Note: DITA-OT uses Java extensions and exslt, which are not supported in latest Saxon home edition. Jarno has been cleaning this up; has done much of it but some extensions still exist (image size in particular; ODT transform type has a lot of items that do not work). Couple of spots today just say - if the extension isn't working - just gives a message that it's skipping validation of something. Frank asks: maybe goal for 1.7, remove anything that won't work with Saxon home edition? Problem is do it a lot in some spots. Jarno thinking - rather than Java extension that reads image information, add as pre-process that adds the image info as metadata. George: there are ways to do extensions with Saxon home edition, but need to write more code to do it (implement an interface, register them); another possibility, implement custom URL like Image Metadata that returns XML doc with the necessary information.
• Unit tests: anybody want to help write JUnit? Also will be further updating our test suite.

Item 4: Other items / discussion

• Recently posted on dita-users: current PDF transform constructs page sequence poorly (not flexible enough). Eliot made some deep hacks to that to get his book out - create single page sequence across chapters, etc. Would like to work with Jarno to adapt the hacks into the current PDF process. Jarno has also thought some about this - need to separate chapter processing from page sequence processing. Added in 1.5.4 the ability to not automatically re-order, instead, respect order of topic references in map. But page sequence generation needs to be revamped; maybe some code rewritten to use XSLT 2.0 features to avoid code duplication (as in attribute sets).