Version:1.0 StartHTML:0000000149 EndHTML:0000003853 StartFragment:0000000199 EndFragment:0000003819 StartSelection:0000000199 EndSelection:0000003819 DITA Learning 5 APR 2012 Minutes
Attendees:
Eric Sirois
John Hunt
Scott Hudson
Troy Klukewich
Hal Trent
Robert Anderson
Amber Swope
Mark Myers
Minutes:
John provided a brief summary of the proposals for Eric and Robert.
Essentially will be adding 26 new elements to the standard with this proposal.
Robert: may be worth re-defining the original specification to be specialized off of div rather than fig. This may only be an impact to fallback processing and tools with existing rendering that maps to the full class hierarchy values, rather than the single specialized class. May also be an impact if the original document embeds these values as well (not recommended anyways).
Need to specifically call out this as a change/new feature in the specification.
Need to have the DTDs modified to call the appropriate modules/domains for the new div basis.
Default processing should still work, but any custom processing may have to be reworked by the implementors.
John: may have an issue with existing title. lcInteractionLabel is proposed to replace it.
Robert: that would be a problem. Might want to bring this issue up to the TC to see if there are any other ideas/options. Not sure the TC will be thrilled to add 26 new/duplicated elements, but can’t break backwards compatibility either.
Perhaps would be better to adjust naming so it’s not just adding number2, but have something like div. Wouldn’t need to duplicate any elements where the locations are the same (If they were based on p, for example).
As far as kosher-ness of Eliot’s proposal, Robert would still like to discuss further with Eliot.
May be able to put a “temporary bridge” out on sourceforge (similar to way that Publishers was done), where the specialization is made available and would require people to migrate title to lcInteractionLabel.
It might work better to have this delivered as a separate spec (isolated) from the main spec, then it could break backwards compatibility.
Hal: the more we get into it, we are finding that the existing spec is lacking quite a bit. We ran into issues with styling b/c of fallback processing of fig. Because there are some known differences in the way it’s been implemented (not everything works in Moodle), would it be bad to break the backwards compatibility?
Robert: if we can split this off, we wouldn’t need to call it Learning and Training 1.3, but could call it 2.0 to really mark this as a separate specialization.
Amber: how would we differentiate the needs for the different use cases? Do we come up with something different the way Task was redefined by Machine Industry?
Hunt: we need to be positioned with a flexible enough model to allow future specializations by specific companies (using this standard as the base, but giving them the starting point to do their own specializations). Still want to attain the “Starter Kit” approach.
Scott: what about Simplified DITA? Do we need to make our proposal compatible?
Robert: Simplified is a separate, highly constrained DTD, so will not need to make compatible. This proposal would be targeted for compatibility with full DITA.
ACTION: John to communicate to Don and Kristen about how we should approach this specialization and what to do about the title situation.
|
Meeting - OASIS DITA Learning and Training sub-committee (Conference Call)