OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: DITA Technical Committee Meeting Minutes: 8 March 2011


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

8:00-8:05 Roll call

o  Regrets: Eliot Kimber; Eric Sirois
o  Quorum was established.


STANDING BUSINESS:

Paul Grosso wanted clarification of the description of our process in the minutes before we move to approve the minutes. All his questions have been answered except for needing a URI for learning and training discussion of XHTML or processing extensions (or expectations). We all agree that as a matter of good TC process, minutes should include URIs to referenced materials, and questions springing from the minutes should be answered as soon as possible.

ACTION (Kris): find the link to the relevant examples for learning and training discussion of XHTML or processing extensions (or expectations) and post it.

Approve minutes from previous business meeting:

     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00015.html (Stan Doherty, 8 Mar 2011 19:11:32 -0000)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00018.html (Paul Grosso, Tue, 8 Mar 2011 15:07:16 -0500)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00024.html (Stan Doherty, 14 Mar 2011 19:00:14 -0000) Modified minutes
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00025.html (Stan Doherty, Mon, 14 Mar 2011 15:01:29 -0400) Explains modifications
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00026.html (Paul Grosso, Mon, 14 Mar 2011 16:11:13 -0400)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00031.html (Paul Grosso, Tue, 15 Mar 2011 09:10:39 -0400) 

  o  Moved by Don to accept the modified minutes as posted in msg00024; seconded by Paul; approved by acclamation.

Subcommittee/liaison reports:

  o  OASIS DITA Semiconductor Information Design Subcommittee -- report next week

ACTION (Seth): make the necessary contact to arrange the report of the OASIS DITA Semiconductor Information Design Subcommittee next week.


BUSINESS:

1.	ITEM: FAQ item about "Question about the order in which keys are resolved"

  o  Ready for TC review; see FAQ-items
  o  Wiki review page: Review-FAQ-#1
  o  E-mail:
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00030.html (Kris Eberlein, Tue, 15 Mar 2011 09:04:39 -0400)

Kris posted a message to the list this morning (msg00030) asking members to check the introduction for ambiguity. Chris Ritchie found that section unexceptionable. 


2.	ITEM: FAQ item about "Key resolution for complex <topicmeta> content"

  o  Ready for TC review, see http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00008.html
  o  Wiki review page: Review-FAQ-#1
  o  E-mail:
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00014.html (Chris Nitchie, Tue, 8 Mar 2011 14:01:56 -0500)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00017.html (Su-Laine Yeo, Tue, 8 Mar 2011 11:18:42 -0800)
     Su-Laine suggests that we need a deadline on this to keep it moving to conclusion over the next week or two. Chris suggests merging his comments into the wiki page. Kris will do this.

ACTION (Kris): merge Chris's comments into the FAQ item about "Key resolution for complex <topicmeta> content" on the wiki page


3.	ITEM: Conditional processing before/after keyspace construction
  o  E-mail discussed at 15 February meeting:
     *  http://lists.oasis-open.org/archives/dita/201102/msg00022.html (Su-Laine Yeo, Tue, 8 Feb 2011 13:11:58 -0800)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00023.html (Eliot Kimber, Tue, 8 Feb 2011 15:21:33 -0600)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00024.html (Su-Laine Yeo, Tue, 8 Feb 2011 13:29:59 -0800)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00025.html (Su-Laine Yeo, Tue, 8 Feb 2011 15:37:54 -0600)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00026.html (Kris Eberlein, Tue, 8 Feb 2011 16:56:26 -0500)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00027.html (Su-Laine Yeo, Tue, 8 Feb 2011 14:23:27 -0800)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00028.html (Robert Anderson, Tue, 8 Feb 2011 17:36:42 -0500)
     *  http://lists.oasis-open.org/archives/dita/201102/msg00029.html (Eliot Kimber, Tue, 8 Feb 2011 16:44:03 -0600)
  o  Action (15 February): Michael Priestley and Robert Anderson to have a call; they'll discuss this item (among others) and post to the list.
  o  Left open to hear from Michael Priestley

Michael, Robert: Eliot's assessment seems reasonable. The spec needs to be clarified. We can't fix the ambiguities until the next revision of the spec. Should probably be part of the FAQ items about keys. For 1.2, the clarified language can recommend what Eliot has suggested, but must allow for the ambiguity. We need to move forward with Eliot's description as a FAQ item, subject to review to ensure that it represents the consensus of the TC. 

OPEN pending completion and review of the FAQ item on keyspace construction relative to conditional processing.


4.	ITEM: General implications of multiple uses of the same topic with different keys
  o  E-mail discussed at 15 February meeting:
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00036.html (Eliot Kimber, Sat, 12 Feb 2011 06:57:41 -0600)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00037.html (Chris Nitchie, Mon, 14 Feb 2011 17:05:47 -0500)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00038.html (Eliot Kimber, Mon, 14 Feb 2011 17:31:26 -0600)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00040.html (Chris Nitchie, Mon, 14 Feb 2011 22:04:02 -0500)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00041.html (Eliot Kimber, Mon, 14 Feb 2011 21:47:07 -0600)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00042.html (Chris Nitchie, Tue, 15 Feb 2011 08:27:22 -0500)
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00043.html (Eliot Kimber, Tue, 15 Feb 2011 07:56:28 -0600)
  o  E-mail discussed at 22 February meeting:
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00053.html (Eliot Kimber, Thu, 17 Feb 2011 06:36:05 -0600)
  o  New e-mail:
     *  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00021.html (Robert Anderson, Mon, 14 Mar 2011 10:58:29 -0400)

We can't tackle this properly without Eliot present, but we need to summarize here. Eliot's idea is that if someone is using two keys to refer to the same resource, the probable reason is to differentiate the two instances, e.g. to result in two different copies in PDF. There are other use cases: one might use placeholder keys initially and later discover that they refer to the same resource; one might want to enable future differentiation, but at present the keys have the same reference; two teams happen to use the same resource and later combine some of their content fortuitously in one key map. None of these have the expectation of creating a new copy. Further, it is an emergent property, and so apt to be a surprise. Stipulating this behavior as a norm requires that there be a mechanism to override it at need, further complicating DITA. People should be able to differentiate when they need to; that's the use of the @copyto attribute, which may need to be refined to serve Eliot's use cases. 

Chris: Eliot did concede this point. He wanted processors to do the right thing when it's obvious that's what is intended.

Michael: What made the conref push case special? Chris: Eliot's point is that there's no other way to interpret that code. Michael: consider the example of two teams. Chris: I wish I'd made that point. 

Further discussion needs to include Eliot.

Kris: The Adoption TC should do some work on the @copyto attribute. Many DITA users have no understanding of it. 

Michael: If you want to say I'm using topic1 in two places, and I want to link unambiguously to just one of these. You could rename one of them to topic2, but @copyto provides a way to label them unambiguously.

Kris: When we pick this up with Eliot present, we need to see how the examples currently in the spec apply to this issue. 

HOLD until Eliot, Michael, Robert, and Chris are all on the call


5.	ITEM: Extensions to DITA filtering using subjectScheme classification

  o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00073.html (Jonatan Lundin, Wed, 23 Feb 2011 11:50:39 +0200)
  o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00083.html (Jonatan Lundin, Thu, 24 Feb 2011 17:32:40 +0200)

HOLD until Jonatan Lunden can call in; he can attend on March 29. 


6.	NEW ITEM: <required-cleanup> element

  o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00022.html (Kris Eberlein, Mon, 14 Mar 2011 10:59:01 -0400)

What's in the spec is inconsistent with what's in the .mod file. Robert: In the DTD it's defined with ANY as content model. The question is why it's different in <concept>, <task>, and <reference>. It's because there are different elements in those document types, so ANY refers to a different inventory of available elements. The spec says the content model is ANY. This is consistent with the DTD and technically correct but not as informative as it should be. 

Why is <required-cleanup> not valid in <refbody>? It's in <conbody> because it's simpler -- <required-cleanup> therefore was not removed. For <task> and <reference> the approach was to ask what elements are needed, and <required-cleanup> wasn't included. 

Some clients have had documents with <required-cleanup> as a root element, and some applications have validated it. Appropriate behavior is to recognize it as valid XML but to report to the user that they are loading something that looks like DITA, but is not, and indicate why and where.


7.	ITEM: DITA 1.3 process

  o  http://lists.oasis-open.org/archives/dita/201102/msg00008.html (Robert Anderson, Mon, 7 Feb 2011 11:29:49 -0500)
  o  Wiki page: Proposed process for DITA 1.3 features
  o  DITA 1.3 proposal template (draft): http://www.oasis-open.org/apps/org/workgroup/dita/download.php/41383/1-3template.dita
  o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00012.html (Paul Grosso, Tue, 8 Mar 2011 11:53:01 -0500)

HOLD to next week, with urging to members to review the templates.


8:50-8:55 PT Announcements/Opens

Stan: There has been some discussion of a TC get-together. Kris: JoAnn has added an open discussion on DITA at the end of Tuesday at her conference. 

Kris asked how many will miss the April 5 TC call because of the conference. It appears that it will not threaten quorum.

8:55 PT Adjourn



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]