-
Notifications
You must be signed in to change notification settings - Fork 193
Meeting minutes 2023 05 04
Attendance: Roger Sheen, Chris Papademetrious, Radu Coravu, Josh Johnson, George Szabo, John Pashley, Robert Anderson, Jarno Elovirta, Frank Wegmann, Will MacLean,
4.0.3 project board: https://github.com/orgs/dita-ot/projects/41
Project board for next release: https://github.com/orgs/dita-ot/projects/36
Ops board: https://github.com/orgs/dita-ot/projects/39
Saxon has released a new version 12.2 that resolves issues Jarno saw with the last one; trying to test that now. Started this upgrade work with Saxon 11 but had issues, all of those seem resolved now. These versions came with new catalog resolver that had issues, seems working now. These code changes block you from going backwards to Saxon 10 which is sort of a big deal ... if you have an enterprise license for Saxon 10, you would not be able to upgrade until you purchase the license for 12. Could hinder adoption. Also have slight concern that this could break some edge case somewhere (for example we do not have Windows machine to test html help and verify it works there). Chris can help test, has a windows VM. Code is currently in feature/saxon12, not merged.
OASIS 2.0 grammar update is coming - has a catalog fix reported in our issues tracker, and gets rid of obsolete / removed xNAL and classification domains.
XDITA - Frank will be meeting with Kris about bringing the grammar up to date, would be nice to make those changes and get into 4.1.
Jarno doing bunch of lwdita related items, will get bundled with 4.1.
Timing -- had originally thought about rushing before convex, then thought soon after convex. We're now two weeks after, so what is the thinking?
- Robert: think that if we can get Saxon update and LWDita grammar updates, those really are release highlights that make it work 4.1. But this means wait while we update/test/bundle those
- Jarno: probably ready in a couple weeks, but also need to have doc changes from Roger
- Roger: lots of lwdita related updates along with the usual release notes. With couple weeks for the changes, then docs after, likely need May to complete that - hopefully by next call we will be ready.
- Frank: lwdita grammar changes likely not significant just need to find the time to get them completed
- discussion of lwdita changes (grammar vs spec), need to verify whether lwdita updates also come with changes that would modify how it has to be handled
- discussion of lwdita and inline HTML -- related to https://github.com/jelovirt/org.lwdita/issues/160
Will plan to do dependency updates soon as well (FOP and others), would be good to have those ready for testing together.
Doc issue raised noting inconsistency / quirk in how filter attributes are handled in lwdita, got that merged: https://github.com/dita-ot/docs/pull/469
Have some items related to project files coming
Had discussion with Mark Giffen about some suggestions he made; have that queued up in to-do list.
Discussion items:
- Do errors in XSLT fail the build in strict mode? Robert has seen in the past that they did not -- cannot remember if there was an issue or if this was resolved. John Kirkilis raised this in slack.
Changes in Saxon might have broken this. When you throw a message from xslt, we pass out a processing instruction that gives ID and level. The years-old code should check the level at that point and fail for errors. Not sure how it impacts for example stack traces. Do remember adding code to pass out the ID and level. But - Saxon has changed its API for messages, so possible that it no longer works.
Need to create test case and validate; likely also need to test with latest Saxon, the one coming with 4.1.
- Unresolved keys are treated as info messages. The spec allows a key to be unresolved as an intentional way to use fallback links (or no link). Robert's (somewhat hazy) memory: some people took advantage of that early on, but initial DITA-OT implementation threw a warning or error; this was downgraded to info because the use case was valid. From discussion in various venues, most commenting today would prefer to treat this as warning or error. Not sure if that is because few people use that original use case, or because the ones using it are happy so don't speak up.
Chris: this is show stopper condition for our case. Might be possible in our case to redefine the info message to treat it as fatal. Problem is, dita-ot code today that looks up message, does not anticipate 2 messages with same ID. If the message ID had a last() type lookup, it would allow overrides. Problem with that - there is no guarantee of order of embedding for messages, your plugin could come first or last.
Some related discussion already here: https://github.com/orgs/dita-ot/discussions/3922
Also here: https://github.com/dita-ot/dita-ot/issues/3950
- DITA-OT webinar in the fall? Wondering about an hour or two that focuses on changes / improvements from last hour. Not other sessions like with dita-ot day. Maybe a whats-new and then discussion. This idea seems much better than moving the normal dita-ot day to webinar with lots of sessions.
Project boards: https://github.com/orgs/dita-ot/projects/
Time to go through pull requests, issues tracker, determine how to handle open issues.
View the latest DITA Open Toolkit docs at www.dita-ot.org/dev.