TC Minutes for 18 May 2010

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

Minutes for 18 May 2010 DITA TC meeting (taken by Bruce Nevin)
 
8:00-8:05 PT Roll call (the meeting had quorum)
 
Approve minutes from previous business meeting:
    *
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201005/
msg00000.html
(11 May 2010 meeting, Day) 
> Don moved, Seconded by Bruce Nevin, no objections; approved by
acclamation.
 
Subcommittee/liaison reports
    * OASIS DITA Learning Content Subcommittee (John Hunt, IBM)
John has chaired since Fall of 2007. Spec, content types, domains. Eager
for approval of DITA 1.2 later this year. Very encouraging updates as
draft spec etc. have been made available, many from the recent CMS
conference. Most vendors support L&T or plan to. Case study by Oberon
Technologies, working with The American College (training & courseware),
Mandate from Dean, have moved to full adoption, 4500 DITA topics. F2F
with SC members and observers. Troy K.'s presentation well received. All
review comments taken care of. 
 
Don: Everyone must maintain the list of adopters up to date.
 
Action Items:
    *
http://www.oasis-open.org/apps/org/workgroup/dita/members/action_items.p
hp
 
Those with due or overdue items should close them ASAP. 
 
Appropriate acknowledgement of Dana Spradley in the 1.2 Acknowledgements
-- carried to items below.
 
BUSINESS: Key links:
   1. ITEM: Mary McRae attended to walk us through process and timeline.
http://wiki.oasis-open.org/dita/Timeline_for_draft-to-approval_process
There is no requirement for a list of implementers for Public Review,
though it's nice to have.
 
Have meeting, approve overview document that links to all parts of spec.
(We now have all in just one specification document, much simpler.) We
approve the spec. One of the editors updates the CS number, note that it
passed, put request to Mary to put it in the OASIS location. Zip as
attachment is OK. Mary checks the document against the checklist (we
should have done this previously). She may return it for fixes. She will
then post it for public review with instructions. All comments must be
submitted to the comment list. If we receive comments directly,
acknowledge with thanks & request to submit properly. 
 
We can't create a new revision (new number) during review. We can create
new revisions internally, for review and incorporation once the public
review is over. Cannot designate them as committee drafts, only as
revisions to the existing committee draft. Cannot invite people to see
these drafts or our discussions of them. We can say how we intend to
address a given comment, but can't put out the revision as such. Track
revisions in comment resolution log or in some other suitable way. Can
request JIRA issue tracker if we want, or use spreadsheet, or the like.
Can use wiki page if we wish.
 
Review period ends at 60 days. As long as even a single comment has come
in, can't do anything for seven days. With revisions, may want to go out
for additional 15 day review--if substantive changes, must do so.
Substantive: would it break an implementation that might have been made
conforming to the spec as sent to Public Review. Then prepare new
revision, vote to approve as new committee draft. Vote to submit to
committee specification ballot. Mary needs comment resolution log
(exported to document, uploaded to Kavi). Mary then runs the CS ballot. 
 
OASIS approval for our look and feel: Send it to Mary for approval.
Would like us to upload it so the transforms are on the templates page.
DocBook has a guide for proper usage of their 'template.'
 
Recommendation that we don't defer things. If there are things that need
change, change them before we send the review draft out. Or if leaving
holes, note them, and know up front that doing so requires a subsequent
15-day review. If big holes, do more than 15 days. If more than an
occasional red line, give reviewers time. Reviewers naturally would
prefer to review only once, or as few as possible, and be finished.
 
Kris: Things that typically come up to be deferred are refinements that
don't affect the content, such as correcting the index, correcting
effective markup for consistency, XSLT conformity to OASIS templates.
Mary agrees these are low impact and can be deferred without objection. 
 
Mary asked how our discussion of packaging was resolved. Kris: as simple
as possible, no multiple packages, just as needed for particular
communities. Mary very pleased that we're doing a CHM. Michael: why do
packages make the review more difficult? Mary: which package makes up
the spec? As long as we can say the spec lives here, in this full
package, and these other things are subset distribution, that's fine.
Don: we'll include instructions on how to build a subset. Mary agrees
this is good. Mary: it would be good to formalize the vertical community
divisions. XACML and SAML have profiles, for example. Must then update
the profiles as well as the spec, but you'd want to do that anyway.
 
Su-Laine: links between topics would be helpful. Can we do this during
the public review? Mary: Yes, no impact on substance while increasing
usability. Feel free to add the CHM link for public review if we want.
Don: we prefer not, because it's difficult for users to provide an
address for a comment. Mary: If some bit is left out of the CHM, just
detail that. We could provide the CHM for those who want it for
usability, with instruction to use the PDF as reference frame for
comments.
 
ACTION: Mary to put link to checklist in the wiki page.
 

2. ITEM: Check on schedule:
 
Kris noted the sad news that Eliot has been called away with somber
family responsibilities (his father's death)A number of TC members
stepped in to help with his items.
 
         * Review comments all completed.
Overview document needs review, Kris feels that it needs some revision.
TC members should send email to the list about desired changes before
next week, so that we all get notifications. TC members need to update
the overview file by sending content to the alias for Kris, Gershon, and
Robert.
 
Su-Laine: Add relationship table during public review. 
 
Kris: How do we get appropriate OASIS URLs for inclusion in these
documents. Robert: Last time that involved considerable back-and-forth
communication with Mary to get them right. We hope there's a better
process now. Robert will help Kris with this. Must be done before public
review because it involves the cover pages. 
 
Kris advised us that some of the links in the formal TOC presently don't
resolve properly in the XHTML output.
 
ACTION: Kris: open new wiki page for short review between now and Friday
of this week.
ACTION: Robert: Assist Kris and Gerson with updates to the overview
file.
 
Don: Next week focus on necessary updates and on fixing outstanding PDF
problems.
 
9:01 PT Don adjourned the meeting