DITA Technical Committee Meeting Minutes: 31 May 2011

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

DITA Technical Committee Meeting Minutes: 31 May 2011

Chaired by Kristen Eberlein <keberlein@stl.com> 
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
 
The DITA Technical Committee met on Tuesday, 31 May 2011 at 08:00am PT for 55 minutes.

8:00-8:05 Roll call

 o  Regrets: 

> Quorum was established.

DITA Technical Committee Meeting Minutes: 31 May 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, 31 May 2011 at 08:00am PT for 55 minutes.

8:00-8:05 Roll call

  o  Regrets: Don Day

> Quorum was established.

STANDING BUSINESS:

Approve minutes from previous business meeting:

  o  http://www.oasis-open.org/committees/document.php?document_id=42290 (Stan Doherty, 24 May)

> Moved by Kris, seconded by Bruce, approved by acclamation.

Subcommittee/liaison reports:

  o  OASIS DITA for Programmers Subcommittee (May 31 -- any progress? Is there still interest?)
   * http://lists.oasis-open.org/archives/dita/201010/msg00075.html

> Lisa Dyer will probably take over leadership from Robert, has been talking to John Hunt.

Action Items:

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

BUSINESS:

1. New ITEM: <anchorref> in <relcell>

   * http://lists.oasis-open.org/archives/dita/201105/msg00020.html (Nevin)
   * Action for Robert Anderson to think about run time behavior and write up a description.

CLOSED

2. New ITEM: Triage of DITA complexity list and potential solutions

   * Wiki page: "What do people (really) mean when they say "DITA is too complex"?

> This was skipped last week:

> [ISSUE-1] DITA contains support for domains that users do not need.

> [SOLUTION-5] DITA TC should create a set of constrained document types that remove some elements.

> Nancy Harrison: Should include Solution 4, which is about domains. Stan concurs.

> [ISSUE-2] DITA users do not need to know how to create new doctype shells easily.

> [SOLUTION-4] DITA TC should create default document types that include fewer domains a la base topic.

Robert: solution 5 proposes a useful starter set that can be expanded. 

>Kris: in Europe, a surprising number of people are using older DTDs and making modifications without creating doctype shells. Robert: Creating shells is a lot easier than creating specializations. Kris: A number of organizations adopted pre-OASIS DITA 1.3.2 and modified it. 

>Chris Nitchie: May need a specialization of <map> to support this. Robert: Michael Priestley has suggested such a thing.

>Kris: This may be something we need to recommend to the Adoption TC. Bruce: we had some discussion of need of draft material from this TC that the Adoption TC can buff up into a white paper.

>Robert: New doctypes are our work.

>Kris: this makes people reluctant to move to a new version of DITA.

>Eliot: If you created documents under an old DTD, you could change the public identifier to point to the new DTD, with no other change to documents or code. As long as you don't use the new features, moving to a new version has no impact whatsoever. Processing remains the same. Then they can plan more considered migration to more modern tools. 

>Chris: They might have some specializations without a class attribute or other modifications that don't follow the DITA rules. Eliot, Robert: But at that point you're not doing DITA.

>Kris: I don't think these are people who are complaining about DITA complexity. 

>Bruce: Does the Adoption TC have a paper on doctype shells? Eliot: yes, there is a need for something that is more official than my tutorials.

ACTION (Kris): Bring this to the attention of the Adoption TC.

>Specializations and shells: Solutions 6 and 9 are the same. Solutions 7 and 5 are the same (including features as well as elements).

>DITA Requires Conceptualization Changes

>Issue 7 and 8 have no solutions. Struggle with the OT is not a DITA TC issue. Robert: I certainly agree, but this also applies to other tools.  Thilo: could better documentation help? >Kris: Adoption TC likewise tries not to focus on any particular tool. Dick: A book on the OT is near publication. 

>Issue 8: Should we have an index into the attributes like that which we have to elements, where they are used.  Robert: This is difficult. It would add greatly to the page count. Some attributes are used differently on different elements, as for example @href restricted to map in mapref; some attributes are used on every element. Robert happy to work with whoever would like to develop this.  Bruce: a reference separate from the lang ref? Kris: that would be the Adoption TC. Robert: we'd help them. 

Robert: suggest a DITA 1.3 item to develop a better way to present attributes. 

>Nancy: The docbook ref includes a page with a list of elements and one-sentence definitions. It's a very useful quick reference to the elements that are there. Robert: at the end of the spec, in sectin 3.5, we have an a-to-z guide. In the HTML they are links, and the short description is displayed when you hover over it. Kris: in the PDF I think it's just a list of hyperlinks.

ACTION (Nancy): post a link to the DocBoook list of elements and their short definitions.

3. Future ITEM: Triage of DITA_1.3_Proposals list (Initiate later)

>Kris: was there a process for 1.2. Robert: for 1.3 we want to use the process that we've developed. It includes an initial evaluation that weeds out items that we decide don't merit spending the time to create a new proposal. For a number of items, the original champion is no longer on the TC (e.g. Ogden, Kravogel, Yeo. If no one takes it up, we do not pursue it. We also require use cases and, ideally, a proposed solution in the first stage. 

>Kris: do we want to have any of our potential solutions to DITA complexity drive DITA 1.3 proposals? Robert: any such solution will have to be written up and vetted like any other. Kris: Should we pay attention to  whether DITA 1.3 proposals add to or reduce complexity? Does that weight our evaluation of proposals? Robert: Paul Grosso asked for a section of each proposal that addresses complexity. I think a lot of people on the TC will give great weight to that section.

8:55 PT Adjourn