As I'm looking at the list of DITA 1.2 items, and thinking of how to
implement these in the DITA Open Toolkit, I'm worried. It's probably the
same worry that Paul Grosso and Jeff Ogden have expressed about 1.2 scope.
Basically, there is a lot to do, and if we stay on schedule, there won't be
a lot of time to do it.
A couple of things to consider - we've talked about modularization of the
spec. In order for the 1.2 spec to be put to vote, we have to have at least
2 implementations in use. With our modularization, I think that means that
each module has to have 2 people to vouch for it, or that module is not
part of the DITA 1.2 spec. That simplifies things for implementors who
won't do the modules that their customers don't need ... but there is still
a lot that everybody needs.
So what if we stay on track with our plans for finishing DITA 1.2, but plan
on a longer review time for the draft? Don't remove the pressure to finish
the spec, but once it is done we give implementors time to catch up before
we officially enter the OASIS approved reviews. Note that this doesn't mean
leaving more time to discuss open items (we can't start implementing items
that are still open). Rather, it means finishing our own review of the 1.2
spec, moving on to 1.3 while many of us work on implementations, and voting
on 1.2 a little later. This note is mostly to bring up the idea before
Tuesday's meeting, so that we can discuss it there.
For reference, I went through the list of 1.2 items and came up with the
lists below. We can't start work on the items that aren't done (which
includes all of the biggest items). I've listed those first. Next I've got
a list of everything, broken up by the sort of impact. I rather arbitrarily
split that by items that hit all tools, and items with less impact (mostly
new elements). The lists are based on
http://wiki.oasis-open.org/dita/DITA_Specification_1%2e2_Requirements
Major incomplete items:
12007 keyref -- Does seem to be near completion
12011 More general task type -- Also probably near completion
12014 Conref and conditional processing -- Michael needs to submit a
proposal
12015 Conref push -- Michael needs to submit a proposal
12021 Nested sections -- unsure of the status
12026 Glossary -- Design in, but waiting on other features
12031 Controlled values -- waiting on keyref
12035 collation element -- This may have been removed, but I'm not sure
12047 mapref/topicset -- Waiting for an updated proposal from Eliot (?)
"Minor" incomplete items:
12022 un-ennumerate attributes -- Eliot needs to submit a proposal
12043 draft-comment in more places -- Eliot needs to submit a proposal
12050a your issues for longdescref, scope, etc -- Michael needs to
submit a proposal
12060 verbatim inclusion of text -- Michael needs to submit a sample
Incomplete subcommittee items:
12024 Machine industry hazard domain -- unsure of status
12038 Acronym -- waiting for final proposal from committee
12058 Learning SC -- I think a proposal is ready, but I'm not sure of
the status
Of all items (complete and incomplete), here is my rough guess at those
which have the most impact:
12007 keyref - On the "major" side of a minor to major scale, because I
think there will be a lot of use cases / edge cases to work out. I may
be proven wrong on this.
12008 - constraints - will require some changes to conref to ensure
validity
12010 domain / topic integration - requires changes to generalization
processors
12013 conref range - medium hit to toolkit, harder for editors that want
in-line display
12015 conref push, guessing a lot of work
12026 glossary -- mostly a DTD/Schema hit, but I think it's got a lot of
new stuff, so guessing at major
12031 controlled values -- guessing a big one
12017 reconcile metadata in maps/topic - tools that push metadata
to/from maps must be updated
12018 elements for translatable text -- medium hit, mostly to tools that
use @navtitle everywhere
12048 headers in reltables - probably small but not sure, particularly
around inheritance/cascading
12055 referencing behavior of