DITA Technical Committee Meeting Minutes: 19 April 2011

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

DITA Technical Committee Meeting Minutes: 19 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, 19 April 2011 at 08:00am PT for 55 minutes.
8:00-8:05 Roll call
  o  Regrets: Paul Grosso, Richard Hamilton
> Quorum was established.

> Don and Kris will both be away May 24; Bruce will chair; we will need a scribe.

STANDING BUSINESS:

Approve minutes from previous business meeting:
  o  http://lists.oasis-open.org/archives/dita/201104/msg00024.html (Nevin)
     * http://lists.oasis-open.org/archives/dita/201104/msg00026.html (Revised attribution, Day)
Don moved, Stan seconded, approved by acclamation.

Subcommittee/liaison reports:

  o  OASIS DITA for the Web 2.0 Subcommittee (Mark Lewis) - next week

Action Items:

  o  Review open items: http://www.oasis-open.org/apps/org/workgroup/dita/members/action_items.php
Covered in business below.

BUSINESS:

1. ITEM: FAQ item "How should elements with keyref attributes be rendered? (formerly '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-
  o  Rendering keyref-bearing elements: using topicmeta vs local content
     * http://lists.oasis-open.org/archives/dita/201104/msg00031.html (Yeo and discussion)

> Either could win, depending on the value of the @lockmeta attribute.
> Chris: this overloads that attribute. Su-Laine: inevitable when you're using an existing attribute. @lockmeta is not only used for something somewhat different, but the default is potentially wrong for this new use. Eliot: a control needs to be available to the author to say whether or not they're forcing an override; a separate control may be needed. Kris: may need to defer to 1.3. Robert: certainly can't handle it elegantly in 1.2. We either make it processor choice, or we overload the attribute. Neither choice is good. Su-Laine: the meaning of @lockmeta is right. Could argue that the attribute is overloaded already, because you can only lock all the metadata or none of it. This is peculiar because it's using metadata as actual content. 
> Don: Safest thing is to put out advice to implementors, with an indication where we're going for 1.3. If we build too much functionality and decide to remove it later we'd have backward compatibility issues. Is there any safe recommendation for now? Eliot: Don't use the feature? Don: that's a point for DITA complexity. Eliot: for the specific use case of using term or keyword to reference a glossaryentry, local content is never overriden. This is for lements that employs a keyref but not href. Su-Laine, Robert: That's what we understood too, but it's the opposite of what the spec says.
> Eliot: in the topic on processing key references, the second paragraph says that local content should win. Robert: that identifies the elements to put through that list. That would make me happy. Obviously it's not clear to a lot of people, and some people have taken it the opposite way. Eliot: that's how I understood the proposal, and that's what I intended this part of the spec to say. Robert: We need to clarify that these rules for matching element content only apply when the elements that refer to the key are empty. Eliot: Two use cases, (1) I want the content to completely replace, as in glossary, (2) I want control, but I want to use keys for the sake of reuse. Robert: Glossaries illustrate the point, but there's no special treatment involved for that edge case.

ACTION (Su-Laine): complete the FAQ and update the 1.3 list.
CLOSED contingent on action.

2. ITEM: FAQ item about "Interaction between key resolution or key binding and conditional processing"

  o  TC review the draft: "What is the interaction between key resolution or key binding and conditional processing?": http://wiki.oasis-open.org/dita/FAQ-items#Q.Whatistheinteractionbetweenkeyresolutionorkeybindingandconditionalprocessing.3F
     * Wiki page for review comments: http://wiki.oasis-open.org/dita/Review-FAQ-
     * Need Eliot for this discussion

> There has been no discussion this week. Close this item when we're ready to post the FAQ item on xml.org.

ACTION (Kris): Carry out an editorial pass.

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  New wiki page: "What do people (really) mean when they say "DITA is too complex"?
  o  New direction: Discuss solutions by number (refer to previous link)

> Kris: The question is what are the core elements that people really use. Su-Laine: also which attributes, which processing features, and what values to change from the defaults. Don: This can be expressed as the functionality that fits within a simple application. Chris: What is the content model, present that in a straightforward way. Processing features, e.g. topic processing vs. map processing. Attributes on <topicref> require some serious study; for example, the attributes you need to set for an <xref> to an external website. 
> Robert: watch out for any implication that this is all you need. Some have promoted this sort of thing. Kris: I don't think you need to worry about the Adoption TC doing that. They've been very thoughtful. 
> Don: process could handle some of the searching, mapping, attribute values for the user. Chris: Yes, the ArborText editor does that. But some users still create surprises for themselves. Don: we might draft what some of those expected behaviors could be. Robert: a guide for implementers to simplify their use for users? Don: Yes, there's a difference between explaining and actually making use easier. Robert: OK, but I thought this was addressed to users rather than to implementers. Kris: That's out of scope for either TC. Robert: A hazard is that you'll get some who implement ten features and claim to support DITA. The complexity issue is of far more concern to the user base. If implementers want to use as a focus, that's fine. Stan: A simple guide, and some sample files. I can forward this idea from the DITA Help Adoption SC  to the Adoption TC. Kris: make sure they're aware of the wiki page and are considering the issues.

ACTION (Stan): Take these concerns to the Adoption TC.
ACTION (Kris): Make the new page a new heading in the existing wiki page.
CONTINUED for further discussion.

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)
CONTINUED for further discussion.

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)
CONTINUED for further discussion.

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

7. 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

CONTINUED for further discussion.

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