DITA Technical Committee Meeting Minutes: 12 April 2011

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

DITA Technical Committee Meeting Minutes: 12 April 2011

Chaired by Don Day donday@bga.com and Kristen Eberlein <keberlein@stl.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
 
The DITA Technical Committee met on Tuesday, 12 April 2011 at 08:00am PT for 55 minutes.

8:00-8:05 Roll call
  o  Regrets: Doug Morrison
> Quorum was established.

STANDING BUSINESS:

Approve minutes from previous business meeting:
  o  http://lists.oasis-open.org/archives/dita/201104/msg00012.html (Nevin)
Moved by Don Day, seconded by Deb Bizantz, approved by acclamation.

BUSINESS:
1. ITEM: FAQ item about "Key resolution for complex <topicmeta> content"
   o Wiki review page: Review-FAQ-#1
   o E-mail discussed 22 March:
     * http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00046.html (Su-Laine Yeo, Mon, 21 Mar 2011 19:00:32 -0700)
   o Eliot/Michael/Robert review: "Key resolution for complex <topicmeta> content": http://wiki.oasis-open.org/dita/Review-FAQ-#Item.233.3AKeyresolutionforcomplex.3Ctopicmeta.3Econtent
   o http://lists.oasis-open.org/archives/dita/201104/msg00016.html (Yeo, new draft)
     * http://wiki.oasis-open.org/dita/Review-FAQ-
> Su-Laine: Has evolved to a general discussion of how to render content with keyref in it. Spec seems to say that content in <topicmeta> should always win. Discussion with Robert Anderson last night suggested it's desirable to allow an option by which local content would win, e.g. content within an <xref> element, leaving it up to the processor. Processor developers would probably make it a parameter. Michael: This raises concerns about consistency across processors. Probably better to specify an option to permit local content. 
> Chris: Not sure it's needed. The map is in charge, and what the map says should rule. What's special about this case? Su-Laine: Robert said the user would be extremely surprised if they put content in their xref element and it was not used. For content that is not visible, we would expect metadata to win. It's generally the case that whatever you put in an xref element in particular is always used. Michael: From the reuser's point of view, if you want to redirect an xref, you're probably going to want to change the xref text as well, so there does have to be a way to do it in the map rather than in the topic. You summarized pretty neatly the justification for the behavior now prescribed in the spec. That works where the author and the keyref writer are the same person. Fine with adding that as a processor option as long as it's just a processor option. 
> Chris: maybe we need something on the key definition that says which direction the authority lies, and maybe we need something in the topic that indicates that. Su-Laine: yes, maybe an attribute rather than a parameter is better.
> Eliot: Is this analogous to @locktitle? Michael: And don't we have a @lockmeta attribute? That's probably a good candidate. Don: Good discussion, and you're right, we should take it further on the list. Su-Laine: and we should discuss whether that control should be on the key-defining element or the key-bearing element. Michael, Eliot: the key-defining element, per Chris's example. 

CONTINUE discussion on the list and next week.

2. ITEM: FAQ item about "Interaction between key resolution or key binding and conditional processing"
   o Draft FAQ item, drafted by Eliot: http://wiki.oasis-open.org/dita/FAQ-items#Q.Whatistheinteractionbetweenkeyresolutionorkeybindingandconditionalprocessing.3F

ACTION (All)): Review this FAQ item and discuss on the list in preparation for next week.

3. ITEM: Perceptions that DITA is complex
   o http://lists.oasis-open.org/archives/dita/201101/msg00051.html (Stan Doherty, Tue, 18 Jan 2011 11:28:35 -0500 -- recent e-mail on thread)
   o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00069.html (Paul Grosso, 22 Feb 2011 13:13:41 -0500 -- scroll down to bottom of e-mail)
   o Wiki page: "What do people (really) mean when they say "DITA is too complex"?

> Don: What do we want to accomplish here? We can continue taking input, but when do we start formulating actions? Su-Laine: We could start a new section of the wiki on solutions to the problem. Michael: cross-refer solutions to problems. Kris: some solutions are already in the page. Michael: yes, we should abstract them out. 
> Michael, Paul: DITA lite has relevance. Part of the challenge is adoption of features as appropriate. Part of it is (through the Adoption TC) responding to misperceptions, when someone thinks only of those parts of DITA that are familiar to them. (Example of <draft-comment>, which has been in DITA since 1.0.) Eliot: Also the converse, seeing only those features that are used and seeing everything else as unneeded complexity. Bruce: We should be alert to these and formulate them as topics for the DITA Adoption TC to write papers about. Don: e.g. for <draft-comment>, a topic "what's available in DITA for life-cycle management?" 
> Chris: we talked about factoring the spec. Michael: that was the original proposal for 1.2, and it was repeatedly shot down. The problem is the dependency between the chunks. Specializations are always deltas against the base. If you only talk about the delta, it's not useful; if you include the base you're duplicating, with an explosion in page count. Chris: A high degree of interdependence is a pretty good definition of complexity. Michael: in any other context, I'd say you need to go to DITA in dynamic publishing. We have the technology that would support this. It's not too far off IBM's knowledge center strategy. The challenge would be OASIS process, but we would be dealing with different people. Kris: Now would be the time to do that. We have an opportunistic window right now. Eliot: There's no requirement that the spec be published through OASIS. Don: Yes, it's already available through other venues. 
> Eliot: Arch spec has Base, tech content, and Learning & Training. [Missed further comment.] Kris: many of the elements adopters want are specialized, not base elements. Eliot: things like specialization, addressing, conref, these are independent of elements. I'd like to see an eventual future in which these features are core aspects of the architecture independent of the vocabulary.

ACTION (Don): Start a new heading on solutions. 
CONTINUE discussion on the list and next week.

4. ITEM: Question on "Elements that may refer to elements within maps or topics"
   o http://lists.oasis-open.org/archives/dita/201103/msg00068.html (Yeo)
(No discussion)
CONTINUE 

5. ITEM: Question on @locktitle for topichead and topicgroup elements
   o http://lists.oasis-open.org/archives/dita/201103/msg00069.html (Yeo)
   o http://lists.oasis-open.org/archives/dita/201104/msg00010.html (Anderson summary)
(No discussion)
CONTINUE 

6. New ITEM: Editorial Suggestion: Formally define the term "root map"
   o http://lists.oasis-open.org/archives/dita/201104/msg00013.html (Kimber)

>Eliot: It may in fact not be possible to define such a term. Don: It may merit an article.
CONTINUE discussion on the list and next week.

7. New ITEM: Clarification of implications of index-see-also (apparent editorial update?)
   o http://lists.oasis-open.org/archives/dita/201104/msg00018.html (Kimber)
   o http://lists.oasis-open.org/archives/dita/201104/msg00020.html (Grosso)

ACTION (Eliot): put this in the update list and indicate Paul Grosso as the owner.

8. ITEM: DITA 1.2 Survey results
   o http://lists.oasis-open.org/archives/dita/201104/msg00006.html (Summary, posted by Buchholz)
   o http://lists.oasis-open.org/archives/dita/201104/msg00007.html (Full, ")
   o Need TC's discussion on using this knowledge
(No discussion)
CONTINUE

8:50-8:55 PT Announcements/Opens
8:55 PT Adjourn