[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting Notes: 01-06-2-13
================================= MEETING NOTES (01-06-2013) DITA Tech Comm SC ================================= A. DITA 1.3 Specification Take-aways - - - - - - - - - - - - - - - - - - - - - - - We chatted a bit about our experiences during the December end-game for the SC feature proposals. 1. Tom - The process in general worked. - No process can be predicted 100%; impossible to freeze all the variables. - That said, it was not entirely clear what all the Stage-3 deliverables consisted of. 2. Bob - Doing feature proposals with cross-feature dependencies is not fun, - There was quite a bit of last-minute discovery involved with doing any medium- or heavy-weight feature. - Once the requirements/dependencies around the IBM troubleshooting specialization got ironed out, things moved along more swimmingly. 3. Stan - Regardless of what SC members anticipate as the complete set of architectural issues/dependencies, there is almost always another set that becomes visible only when an SC proposal gets up to technical folks on the TC. - Feels that the feature approval pipeline has three stages more frequently than two stages: > SC submission > TC technical architects' review > TC general review B. Brainstorming for 2014 Activities - - - - - - - - - - - - - - - - - - - - - - - What might we consider by way of SC activities in 2014? 1. SC visitors Stan suggested that it might be useful to for the SC to host a series of "visiting DITAheads." The goals are: - Get feedback from different types of organizations using Tech Comm features about what they are encountering - Potentially recruit new SC members / participants - Gather feedback on future Tech Comm features or requirements - Gather feedback on how Tech Comm practitioners are using our spec materials 2. Technical "solutions development" Jennifer suggested that we take a hard look at some of the more challenging implementation issues that our Tech Comm constituents face routinely. - Example: Figuring how to manage keydef libraries across large doc sets WITHOUT creating conflicts can be very tricky. - Example: Resolving conflicts at a meta-product level when reuse libraries that were designed to work at the product levels bubble up to the cross- product level. 3. Yahoo User Group issues Bob reminded us that issues with the Tech Comm feature often pop up on the Yahoo user group discussion list. - Example: <choicetable> versus <substep> logic when you want to route readers based on their choices in a <steps> procedure. Given that software logic can be inherently convoluted, being able to route readers within cononical DITA tasks <steps> is important. - Example: Getting back to Yahoo users with information about the historical logic of our feature decisions would help. Jennifer noted that most companies develop "standard" workarounds for some of these design gaps, e.g. using <ol>s and <ul>s within <choicetable> elements works. Collecting these would be useful. 4. Lightweight DITA Bob recommended that the SC get more involved with the post-1.3 effort known as Lightweight DITA. Michael Priestley had just posted a ZIP archive containing his latest working DTDs and spec information on December 19. https://www.oasis-open.org/apps/org/workgroup/dita/documents.php Providing ongoing feedback with this effort needs to be a priority for the SC and its constituents. Next Meeting: Monday, January 20
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]