[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA Technical Committee Meeting Minutes: 15 February 2011
DITA Technical Committee Meeting Minutes: 15 February 2011
Chaired by Kris Eberlein <kberlein@sdl.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
The DITA Technical Committee met on Tuesday, 15 February 2011 at 08:00am PT for 55 minutes.
8:00-8:05 Roll call
o Regrets: Don Day; Thilo Buchhotz; Robert Anderson; Doug Morrison
o Quorum was established.
STANDING BUSINESS:
Approve minutes from previous business meeting:
o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00016.html (Bruce Nevin, Tue, 8 Feb 2011 11:31:39 -0600 -- Original draft of minutes)
o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00017.html (Paul Grosso, Tue, 8 Feb 2011 12:40:59 -0500 -- Correction to minutes)
o http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00018.html (Bruce Nevin, Tue, 8 Feb 2011 11:52:05 -0600 -- Asking for additional corrections)
Moved by Kris, seconded by Su-Laine, approved by acclamation.
Subcommittee/liaison reports:
None this week. Watch this space in the agenda on the Front Page.
Announcements:
o DITA TC members invited to attend OASIS Process Committee meeting today, 15 February, 11 AM -12:30 PM PT the subject is "OASIS templates for work products."
Call-in information:
id: 9238410#/9876543#
+1 866-682-4770 or +1 408-774-4073 (US)
0800-694-8154 (UK toll free)
+44 208 118-1001 or +44 844 493-6817 (UK)
*6/#6 to Mute/Unmute
For call-in numbers for other countries, contact
Jeff Mischkinsky [jeff.mischkinsky@oracle.com]
BUSINESS:
1. ITEM: Question about the order in which keys are resolved
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/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/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/msg00065.html (Jo!Ann Hackos, Sat, 22 Jan 2011 10:23:25 -0700)
See FAQ-items for a look at this work in-progress.
Action (Kris): do editorial review of Eliot Kimber's draft a FAQ item about this issue.
1. ITEM: Key resolution for complex <topicmeta> content
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)
Su-Laine: we're waiting for clarification from whoever wrote that part of the spec that concerns pulling content out of <topicmeta>.
Eliot: Robert did first draft, Eliot worked on it, Bruce contributed. The original information came from Robert and Michael.
ACTION (Michael Priestly): set up meeting with Robert to work out an answer.
2. NEW ITEM: Conditional processing before/after keyspace construction
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)
Eliot: Intention was that when conditional processing is applied, the set of effective key definitions might differ from that when conditional processing is not applied. It's a function of the content, not of the processing.
Michael: the spec recommends doing conditional processing first, but allows for doing it second, and there's some discussion of what happens in the latter case. [reading the spec]: different processors could reach different effective bindings for the same map when there are key definitions in filter conditions. This part is not correct.
Kris: the correct answer should go in a FAQ to get it out to users as quickly as possible.
Eliot: The set of key definitions is completely deterministic. It's not up to processor determination. Key definition always takes filtering into account irrespective of the relative order of filtering and key definition. This was my intention when writing that part of the spec, although evidently that writing needs improvement. The alternative would make key definition non-deterministic.
Michael: will have to review the spec.
Kris: Let's return to this next week after Michael and Robert confer.
Chris Nitchie: We need to distinguish "key space" from the data structure employed by a processor.
Eliot: yes, this is a source of confusion here. The effective key space permits just one effective binding. Processors may need to hold multiple bindings in memory in order to accomplish this, and that is an implementation detail that is neither mandated nor disallowed by the spec.
Su-Laine: we just need to know for any given input what the expected output is.
Michael: We agree that the should statement is that it should be the same as if the conditional processing is done before the key binding.
Su-Laine: so if we filter first, we're OK. [General concurrence.]
ACTION (Michael, Robert): add this to the agenda for the discussion called for in the action under #1 above.
3. NEW ITEM: Conref range: Is constraint on last member of range necessary or useful?
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)
Eliot: Spec says the first and last elements of the range must be of the same type. I don't think this helps, because it can't ensure the validity of the range between those elements in the using context. Consider removing that constraint in 1.3.
Michael: I concede a long-standing misreading. There are content models that break this, as illustrated by Eliot's examples of sequences of required elements. Understanding this now, I probably wouldn't have proposed conref range. At least the existing constraint ensures that content models in DITA as delivered work. Is there any way for us to get full validity?
Eliot: I don't think we need to. I don't think a guarantee of validity of the results is necessary for conref range to be useful. The problem is limited. It's up to users to avoid this edge case.
Michael: On the other hand, if we remove the requirement, there are a lot of examples in the spec that would be invalid today, where any place in the sequence could be optional or not.
Chris Nitchie: This is a nightmare for implementors.
Michael: Are there any other cases other than what we have identified? Eliot: If the same section type is required more than once in the same reference.
Michael: So we have a constraint that allows an edge case to break conref. It also prevents some valid cases. If we remove the constraint, a lot of cases break conref.
Kris: Continue next week? 1.3 proposal? Push to users?
Michael: We could put out a caution to users, saying that its OK for all content models except this one. And yes, we should revisit this for 1.3.
ACTION (Michael, with Eliot's review): Write a warning to users about this.
4. NEW ITEM: General implications of multiple uses of the same topic with different keys
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)
Eliot: conref push with same topic bound to two different keys permits a push of different content to the same topic with different keys. Aim of processor design should be to effect the author's intent. Question is what may happen, what should happen.
Chris: The perfect processor should do that, but I don't think the spec requires that. When you resolve conref push, the keys may already be abstracted away, and there's nothing in the spec to prevent that.
Eliot: Need to think more carefully about that. In my mind, key resolution is done as late as possible, partly because it can establish a use context, and you need to know the use context to do the right thing.
Chris: I know at least one implementation that works the way I described it. We could be wrong, but haven't yet been proven so.
Eliot: Question to Robert and Michael, was this intended, or was it a result of two independently designed facilities, keys and conref push? Michael: I'll have to catch up to this thread and think about it.
Kris: We'll continue this next week.
5. 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
Skipped this week, since Robert is not here.
ACTION (All): look at this wiki page, because this will be higher on the agenda next week.
6. 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"?
Kris: For those who haven't for completed the survey, time is running out.
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]