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: 22 February 2011

DITA Technical Committee Meeting Minutes: 22 February 2011

Chaired by Don Day <donday@bga.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
The DITA Technical Committee met on Tuesday, 22 February 2011 at 08:00am PT for 18 minutes.

8:00-8:05 Roll call

 o  Regrets: JoAnn Hackos, Thilo Buchholtz
 o  Quorum was established.


Approve minutes from previous business meeting:

 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00048.html (Bruce Nevin, Tue, 15 Feb 2011 11:17:18 -0600)

Moved by Don, seconded by Stan Doherty, approved by acclamation.

Subcommittee/liaison reports:

None this week.


1. Update on OASIS Process Committee meeting about "templates." (Eberlein)

Kris: The meeting was short. They concluded that they didn't have enough templates. Kris urged that they not specify output format, e.g. Word, and is following up to find out if they have any requirements that we should know about.

2. ITEM: Question about the order in which keys are resolved

E-mail discussed at February 8 meeting:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00057.html (Kris Eberlein, Fri, 21 Jan 2011 11:15:56 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00058.html (Chris Nitchie, Fri, 21 Jan 2011 12:37:08 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00059.html (Eliot Kimber, Fri, 21 Jan 2011 12:36:40 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00060.html (Paul Grosso, Fri, 21 Jan 2011 14:17:05 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00061.html (Bruce Nevin, Fri, 21 Jan 2011 13:28:03 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00062.html (Chris Nitchie, Fri, 21 Jan 2011 14:37:13 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00063.html (Bruce Nevin, Fri, 21 Jan 2011 13:45:59 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00064.html (Eliot Kimber, Fri, 21 Jan 2011 13:54:50 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00065.html (JoAnn Hackos, Sat, 22 Jan 2011 10:23:25 -0700)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00090.html (Eberlein, Fri, 28 Jan 2011 09:08:43 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201101/msg00091.html (Eliot Kimber, Fri, 28 Jan 2011 08:19:52 -0600)

ACTION (Eliot Kimber): verify that Kris's changes to this FAQ item retain technical accuracy. See http://wiki.oasis-open.org/dita/FAQ-items.

3. ITEM: Key resolution for complex <topicmeta> content

E-mail discussed at 15 February meeting:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00010.html (Su-Laine Yeo, Mon, 7 Feb 2011 18:23:45 -0800)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00012.html (Eliot Kimber, Tue, 8 Feb 2011 06:21:10 -0600)

New e-mail yesterday:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00059.html (Robert Anderson, Mon, 21 Feb 2011 11:33:42 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00060.html (Chris Nitchie, Mon, 21 Feb 2011 13:45:41 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00063.html (Su-Laine Yeo, Mon, 21 Feb 2011 16:53:57 -0800)

Robert: met with Michael and reviewed the spec language and that of the approved proposal where the original intent was unclearly expressed. Fallback to <linktext> and <navtitle> was not expressed. Chris Nitchie: what they outlined was how it should work, but it's not what the spec says. Su-Laine: I like Robert's answer. How official is it? How shall we communicate it to developers? Have also asked our developers if it works for them. We need to know whether the rules that we've implemented are right.
Kris: Can this wait for 1.2 erratum, or should we put it in the FAQ? Su-Lain: Putting it in the FAQ will save time. Would really appreciate an answer today to yesterday's email. 

Su-Laine: need a response from the TC re (a) How confident are we in Robert's answer? (b) Is it acceptable if a processor strips out markup that is not valid in the new context? Would anyone object to a processor doing that? This is in the email.
Kris: We need to hold this for another week to give people time to consider email of yesterday and the FAQ item still to be written.

Don: if we say that the element will be stripped, does that preclude the vendor from adding more later if an improved solution is made available. Bruce: How about hiding the markup rather than stripping it. Robert: Yes, that's what I would prefer. And I would prefer that we simply allow rather than mandate that behavior. 

Doug: The spec isn't necessarily incorrect, maybe what's needed rather than an erratum is a white book including an explanation. Consensus: not for Adoption TC to write, they address users, this is for implementors. Kris: Let's be honest, we barely have enough people to write a spec.

Su-Laine: Need to call attention to <navtitle>, <linktext>, and <shortdesc> being treated as special.

ACTION (Su-Laine): write the FAQ item. 

4. ITEM: Conditional processing before/after keyspace construction

E-mail discussed at 15 February meeting:
 o  http://lists.oasis-open.org/archives/dita/201102/msg00022.html (Su-Laine Yeo, Tue, 8 Feb 2011 13:11:58 -0800)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00023.html (Eliot Kimber, Tue, 8 Feb 2011 15:21:33 -0600)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00024.html (Su-Laine Yeo, Tue, 8 Feb 2011 13:29:59 -0800)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00025.html (Su-Laine Yeo, Tue, 8 Feb 2011 15:37:54 -0600)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00026.html (Kris Eberlein, Tue, 8 Feb 2011 16:56:26 -0500)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00027.html (Su-Laine Yeo, Tue, 8 Feb 2011 14:23:27 -0800)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00028.html (Robert Anderson, Tue, 8 Feb 2011 17:36:42 -0500)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00029.html (Eliot Kimber, Tue, 8 Feb 2011 16:44:03 -0600)

Per 15 February action item, Michael Priestley and Robert Anderson discussed this.

Robert: Michael took notes on this and agreed to write it up. 
Eliot wrote a draft FAQ on this.

OPEN for next week when Michael can attend.

5. ITEM: Conref range: Is constraint on last member of range necessary or useful?

E-mail discussed at 15 February meeting:
 o  http://lists.oasis-open.org/archives/dita/201102/msg00031.html (Eliot Kimber, Thu, 10 Feb 2011 07:03:18 -0600)
 o  http://lists.oasis-open.org/archives/dita/201102/msg00032.html (Michael Priestley, Thu, 10 Feb 2011 08:25:31 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00033.html (Eliot Kimber, Thu, 10 Feb 2011 09:02:47 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00034.html (Michael Priestley, Thu, 10 Feb 2011 10:21:38 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00035.html (Eliot Kimber, Fri, 11 Feb 2011 05:54:38 -0600)
o	New e-mail:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00052.html (Eliot Kimber, Thu, 17 Feb 2011 06:25:20 -0600)

Eliot: This was my attempt write the explanation that Michael is tasked with. It's what I've currently drafted for my book; Michael is welcome to use it or reject it. Robert: I think this note agrees with what Michael approved.

Kris: did we intend the warning to be in the FAQ or in the 1.2 errata. Eliot: Not particularly urgent, it's such a rare case.

ACTION (Michael Priestley, 15 February):  write a warning
ACTION (Kris): add this to 1.3 work items.

OPEN for next week when Michael can attend.

6. ITEM: General implications of multiple uses of the same topic with different keys

E-mail discussed at 15 February meeting:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00036.html (Eliot Kimber, Sat, 12 Feb 2011 06:57:41 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00037.html (Chris Nitchie, Mon, 14 Feb 2011 17:05:47 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00038.html (Eliot Kimber, Mon, 14 Feb 2011 17:31:26 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00040.html (Chris Nitchie, Mon, 14 Feb 2011 22:04:02 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00041.html (Eliot Kimber, Mon, 14 Feb 2011 21:47:07 -0600)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00042.html (Chris Nitchie, Tue, 15 Feb 2011 08:27:22 -0500)
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00043.html (Eliot Kimber, Tue, 15 Feb 2011 07:56:28 -0600)

New e-mail:
 o  http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00053.html (Eliot Kimber, Thu, 17 Feb 2011 06:36:05 -0600)

Eliot: Since the spec is at best ambiguous about this, we can't say that it mandates the behavior that I wanted. Robert: Michael already has use cases involving documents shared between teams referencing different documents, where this would break user expectation.

Eliot: As to the specific behavior of conref push, I think that my description is correct and to everyone's advantage. The other issue, I agree with Michael. Chris: the spec allows conref push to work wrong. Eliot: agreed. Do we want to clarify? 

OPEN for next week when Michael can attend

7. NEW ITEM: Refinements to DITAVAL for flagging

  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00054.html (Eliot Kimber, Fri, 18 Feb 2011 07:02:58 -0600)
  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00055.html (Seth Park, Fri, 18 Feb 2011 14:15:48 +0000)
  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00056.html (Eliot Kimber, Fri, 18 Feb 2011 09:11:37 -0600)
  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00057.html (Seth Park, Fri, 18 Feb 2011 15:29:19 +0000)
  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00058.html (Eliot Kimber, Fri, 18 Feb 2011 09:48:11 -0600)

Eliot: Hadn't thought about ditaval before, and writing about it for the book realized that some interesting conditional processing was possible. Robert: a proposal for ditaval was filtering by branch. Eliot: not interested in re-engineering ditaval, but maybe extending it.

CLOSED for ongoing discussion between Eliot, Seth, and Robert, and perhaps others.

8. NEW ITEM: Question on keyref processing for <data> element

  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00061.html (Su-Laine Yeo, Mon, 21 Feb 2011 14:11:31 -0800)

Su-Laine: lang ref says processors should ignore <data> by default. If a behavior is desired, must code it specifically. However, for <keyref> there are specific processing directions. We need to know if it's OK not to process it.

Robert: Not processing means not rendering. For <keyref>, it's just touched for key resolution. If people want to render it, the details are in their hands. This falls under the category of elements with @href. 

Su-Laine: It seems that the spec is written with a specific prescription to incorporate the referenced <data>/<topicmeta> into the referencing <data>. Robert: This is underspecified. Su-Laine: let's hash that out on the list and in the FAQ. There's no obligatory processing. We need to  explicitly give processors permission not to insert replacement text.

Robert: This should be a 1.3 item, and we should clarify replacement text for different elements. The list of rules that Su-Laine has laid out answers many of these questions. 

ACTION (Su-Laine): add this to FAQ for item #3
ACTION (All): Review this email discussion and report any issues to Su-Laine for her to consider in the FAQ.

9. NEW ITEM: PDF processing for files containing multiple topics
  o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00062.html (Su-Laine Yeo, Mon, 21 Feb 2011 16:03:37 -0800)

Su-Laine: expectation is 1-1 correspondence of topicref to topic, but some language in the 1.1 spec and elsewhere indicates that you get more. Eliot: for rendition processing you get all referenced subtopics. Robert: you get the full document; you can modify that with the @chunk attribute. Su-Laine: it's confusing to people to put in a topicref with an id to a particular topic and have it pull in additional stuff. 

Not all products do this (e.g. ArborText). Consensus: it's OK not to. 

CLOSED unless and until revived in future discussion.

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

HOLD until next week.

11. CONTINUING 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 -- most recent e-mail on thread)
  o Wiki page: "What do people (really) mean when they say "DITA is too complex"?

No discussion this week.

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

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