[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA Technical Committee Meeting Minutes: 17-NOV-2009
|
DITA Technical Committee Meeting Minutes ======================================== The DITA Technical Committee met on 17 November 2009 at 08:00am PT for 60 minutes. Chaired by Don Day <dond@us.ibm.com> Minutes recorded by Gershon Joseph <gerjosep@cisco.com> Roll call > Quorum was achieved. Approve minutes from previous business meetings: * http://lists.oasis-open.org/archives/dita/200911/msg00100.html (10 November 2009, Joseph) * http://lists.oasis-open.org/archives/dita/200911/msg00101.html (minor naming edit, Nevin) > Minutes approved as amended, by acclamation. Subcommittee/liaison reports (as needed) > None this week Business: Next meeting: 24 November 2009 > Note that the TC *will* meet next week. ITEM: DITA 1.2 specification (revised by Joseph 17 November 2009) * Spreadsheet and DITA topics located in the Subversion repository * Information about contributors, deadlines, editorial guidelines, Subversion clients, and more * Business: a Progress report on spec review #2: All reviews were to be completed by 13 November * Outstanding reviews per review status table: * Jeff Ogden : Technical content > Jeff has been distracted by terminology and other issues he has been > working in. He plans to complete the review before JoAnn returns from > Europe. b Need to revise spec author/review schedule due to the following issues: * Constraints proposals and issues * Discussion around terminology * Work being done to restructure conref/keyref/href material * The following schedule presupposes that the DITA TC resolve all open issues during the November 10 and 17 meetings. If that does not happen, the dates need to shift according to the delay. Is this schedule still realistic at this time? > The TC agreed to push dates off 1 week in the hope we'll close all remaining > open items next week. > Here is the revised schedule (note that Gershon added an extra week for the > review due to the holiday period): > 8 December 2009 -- Third drafts complete; third internal review begins. > This review will include the OASIS DITA Adoption > Committee and the OASIS Technical Advisory Board. > 5 January 2009 -- Third review complete; author begin working review > comments. > 20 January 2009 -- Final draft ready to submit to OASIS for public review > and official-approval process kick-off. This draft must include all > substantive content; if we need to add substantive content after the public > review begins, it will require us to restart the approval process. c Need for authors to handle the following points (we might need to schedule an authors meeting) * Implementing "referencing element" and "referenced element" terminology * Implementing cascade vs. inherit terminology * Moving content of some <draft-comment> elements -> XML comments; for the next review, we should be using <draft-comment> elements only for comments to reviewers. * Ensuring conformance statements are valid, correct and correctly marked up ("must", "should" etc. correctly used and tagged) * Implementing changes needed to ensure prose complies with the new terminology (DITA Document Type, etc.) ITEM: documentation of conref restrictions (ongoing) * http://lists.oasis-open.org/archives/dita/200911/msg00013.html (rollup by Gershon) > Bruce: The initial idea was to have a new topic that discusses the various > items at a high level and links to the detailed topics. After discussion > with Eliot, we decided to rather merge a lot of the content into a single > topic. This single topic is what's up for review, and the TC needs to agree > to go with the new topic replacing the previous topics. > DECISION: The TC agreed to go with this plan. > ACTION: Bruce to update SVN with this change. > CLOSED. ITEM: When does applicability apply to key space termination? (ongoing) * http://lists.oasis-open.org/archives/dita/200911/msg00000.html (Kimber) > Michael: We reached closure on the list. > Eliot: We arrived at the understanding that filtering affects key space > termination. We also came to the conclusion that we could not set a single > rule because of the way a number of users expect filtering to be applied. > Therefore we have to live with the situation that different processors can > produce different results. Jeff and I arrived at wording for this, we need > to decide where to put this. Question – should the spec prefer one behavior > over another? We're closing on not making any judgement. > Jeff confirmed Eliot's summary. > ACTION: Eliot to update the spec to address this. The TC agreed it should > put in an appendix. > CLOSED. ITEM: Terminology for DITA 1.2 spec (concrete document type, local shell) (ongoing) * http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200910/msg00140.html * http://lists.oasis-open.org/archives/dita/200911/msg00135.html (Ogden, rollup from ad hoc discussion) > Jeff: We shortened the list and clarified the terms, moving unnecessary info > to other parts of the spec where necessary. We see this as guidance to the > writers who need to update the terminology topic. > ACTION: Eliot, Gershon and Kris to update the terminology topic based on the > decisions made in the emails that discussed this issue. > CLOSED. New ITEM 10 Nov: DITA semantics potentially affected by filtering * http://lists.oasis-open.org/archives/dita/200911/msg00017.html (Kimber) * Any discussion before submitting this as draft into the spec? > Discussed as part of item 3. > ACTION: Gershon to create a new wiki page that pulls in the issues in items > 3 and 5 into one place for further work by the TC. > CLOSED. New ITEM 10 Nov: Conref of topicref to topicref--relative URLs * http://lists.oasis-open.org/archives/dita/200911/msg00067.html (Kimber) * http://lists.oasis-open.org/archives/dita/200911/msg00083.html (Kimber, looks like a rollup proposal) * (Don asks: Are we at a consensus? Is adding "may" enough? Let's close...) > Eliot: Addresses should be resolved against whatever element actually > specifies the address in the source, not against any conref result. > Jeff: I don't want to prohibit it from being against the conref result. > Eliot: Whatever the address resolved to before conref resolution should > resolve to after conref resolution. > Robert: What does it mean when you conref a section that has a conref to a > local element within that topic? > Jeff: We started talking about conreffing an element, e.g. xref. Now we're > talking about what if the conref element includes a child reference – how do > we resolve that child reference? This is the question Robert is asking about. > Robert: The internal ones are confusing. How are @id values resolved? > Eliot: Nothing in DITA provides enough info to say what the result should be. > We don't have a way of saying what the id resolution context is. So it's > ambiguous. > Eliot: the requirement is: references to resources via URL should resolve > relative to the location of the reference as initially specified and not > with regard to where that reference may end up following conref resolution. > Jeff: I want to leave it somewhat open-ended so that if the processor can't > resolve the relative URI, it can try other things. > Eliot: My concern about leaving the fall-back open-ended is it throws > interoperability out the window. > Gershon mentioned that both behaviors could be considered as correct by > different user groups. > Eliot: This is why we need to identify such interoperability issues so that > tools can provide a means for users to select the behavior they want. > ACTION: Eliot and Jeff to come up with wording. Then address this as an > editorial issue. CLOSED. New ITEM 10 Nov: key reference error vs warning * http://lists.oasis-open.org/archives/dita/200911/msg00085.html (Ogden, others) > Jeff: I think this is almost an editorial item. However we'd be changing the > proposal we agreed to in 12007 that we approved. So instead of being requited > in the proposal, we're making it a warning. > Don clarified this is the result of due diligence in implementing the > proposal. > ACTION: Eliot to make the change in the appropriate topic. > CLOSED. ITEM: Resumption of: task vs. general task, constraints, conref, and other related issues * http://lists.oasis-open.org/archives/dita/200909/msg00368.html (Ogden summary) * wiki summary: Summary of task vs. general task, constraints, conref, and other related issues * Updated UPDATED SUMMARY * http://lists.oasis-open.org/archives/dita/200910/msg00087.html (Ogden, and following thread) * Despite the title of this item, this discussion now only concerns restored items 3 and 4 * Continue discussion from last week (Ogden, Michael, Eliot, and Seth Park's suggestion) * Re-create general task from topic? * http://lists.oasis-open.org/archives/dita/200910/msg00117.html (Park) * Resumption: * http://lists.oasis-open.org/archives/dita/200911/msg00020.html (Kimber) * http://lists.oasis-open.org/archives/dita/200911/msg00087.html (Ogden)--reset of discussion: the 3 options > Jeff: Option 1 follows the rules, but potentially trips up users. Option 2 > breaks the rules in file-naming, modularity. > Michael added that option 2 also prevents mixing generic and strict task. > Jeff suggested that option 2 also changes the spec to say *should* instead > of *must*. > Jeff stated that whatever decision we make he can live with it. Michael and > Gershon also state they can live with whichever decision the TC makes. > Gershon motioned to take a straw poll: > -- Robert - option 1 > -- Stan - option 1 > -- Rob - option 1 > -- Paul - option 2 > -- Richard - option 1 > -- Eliot - option 1 > -- Bruce - option 1 > -- Jeff - option 2 > -- Seth - abstain or option 3 > -- Su-laine - abstain > -- Gershon - option 1 > -- Michael - option 1 > -- Don - abstain > Results: > - option 1 = 8 votes > - option 2 = 2 votes > - abstain = 3 votes > Based on the OASIS rules, we need a "Simple Majority" for this type of > decision, so this vote carries to generate a TC decision. > (The OASIS rules are at http://www.oasis-open.org/committees/process.php#voting) > DECISION: The TC agreed, by Simple Majority vote, to move forward with option 1. > CLOSED. *** Meeting Adjourned ***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]