dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 7 March 2017 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Fri, 10 Mar 2017 22:51:00 -0800 (PST)
Submitter's message
**ActionItems:
1. Tom will find instructions for stage 3 reviewers.
2. Robert will update the draft 2.0 process to say that reviewers need
3. Kris will create a wiki page to track items to add to the Errata 02 document.
4. Kris will open discussion with the group of volunteers who are inteeerested in working on a new high-level design for the 2.0 spec.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 14 February 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Business
========
1. Roll call
Regrets: Deb Bissantz, Eliot Kimber
2. Approve minutes from previous business meeting:
28 February: https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201703/msg00002.html (Nancy Harrison, 6 Mar 2017)
moved by Tom; 2nded by Eric, approved by TC
3. Announcements:
New TC members: None
4. Action items
23 August 2016:
Kris: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN (IN PROGRESS)
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
25 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
21 February 2017
Kris: find someone from the iiRDS working group to come to TC meeting and do presentation.
Kris: correct error in sourc 2.2.3.4 processing controlled att values
Robert, Kris, Dick, Dawn: talk about workflow/admin practices for errata 02
Eliot: Update the grammar files to fix allowed number of in (NEED TO MOVE TO ERRATA 02 TO-DO LIST)
Robert: Correct the content model appendix topics for ditavalmeta / ditavalref for the same. (NEED TO MOVE TO ERRATA 02 TO-DO LIST)
Robert: Correct the ditavalmeta section so the example link goes DIRECTLY to the example. (NEED TO MOVE TO ERRATA 02 TO-DO LIST)
[Kris will clean up this agenda
28 February 2017
Tom: Make sure his minutes from Feb 28 include all the data; some of it didn't come through.
Robert: update 2.0 proposal process to include info on removing something from a shell without removing it from the specification.
Robert: update 2.0 proposal process to include info on referencing deprecated elements/attributes, in case of backwards compatibility issues.
All TC members: review draft of 2.0 proposal process https://wiki.oasis-open.org/dita/DITA_2.0_Proposal_Process_DRAFT
and proposed Stage 2 proposal template https://www.oasis-open.org/committees/download.php/60163/2-0template.html
5. Continuing item: Overview of DITA 2.0 Proposal Process
Continue questions and discussion from last week
Can we agree to approve this procedure as our working process for DITA 2.0?
[continue discussion of Chris's question from last week; 'what can we do to reduce workload on editors?']
Robert; one this that would be helpful would be if everyone can go to Github so we can do our work within that context.
Kris; it would be great if people can learn Github; I'd make it a strong recommendation but not a requirement.
Stan; what if we take a QA approach to the examples in spec? That is, pull them out and test them all carefully; then, by the time material gets to the editors, the examples would be clean.
Kris; we do need that, but it's not such a big-picture item. If the point is to reduce work for spec editors, then anywhere there are new proposals, we need the involvement of enough careful reviewers. The more rigorous reviews we can get (including examples), that's where it's a real help. Somewhere, we had a list of what reviewers should be doing at stage 3...
Robert; I think that's doc'd somewhere. In 1.3 we did do a lot of example QA.
Kris; can we get a volunteer to look thru the mail archives to find the list of instructions for stage 3 reviewers?
Tom; I'll do that
**ActionItem; Tom will find instructions for stage 3 reviewers.
Robert; I'll update the draft process to say that reviewers need to help validate proposals.
Kris; with a link to the document on roles & responsibilities for reviewers.
**ActionItem; Robert will update the draft 2.0 process to say that reviewers need to help validate proposals, with a link to the document on roles & responsibilities for reviewers.
Tom; any other ideas about this? Kris, you had said something in email asking if we were going to approve this procedure this week. Should we do this?
Kris; I think so. we've talked it over, small group developed it, talked it over, made changes.
Kris moved to accept the draft 2.0 process proposal, Robert 2nded, approved by TC, THIS IS NOW OFFICIAL.
Kris; before we make changes to stage 3 templates, we need to nail down what we're thinking anbout release 2.0. We thought we should come up with a basic high-level design for 2.0. We also need to do a basic review of element topics where 2.0 overlaps with LwD.
6. Continuing item: DITA 1.3 Errata 02
Restore DITA 1.x identifiers to catalog files (COMPLETED?)
https://github.com/oasis-tcs/dita/issues/11
Kris in 21 Feb meeting: "I know this has been done, but it hasn't been tracked in the errata document yet"
Error in 3.4.2.4 index-see-also (COMPLETED)
https://lists.oasis-open.org/archives/dita/201612/msg00068.html (Eberlein, 10 December 2016)
Error in example for indexterm (COMPLETED)
https://lists.oasis-open.org/archives/dita/201612/msg00069.html (Eberlein, 10 December 2016)
Error in 3.4.2 Indexing group elements (COMPLETED)
https://lists.oasis-open.org/archives/dita/201612/msg00070.html (Eberlein, 10 December 2016)
Confusion in 3.7.5 index-base (COMPLETED)
https://lists.oasis-open.org/archives/dita/201612/msg00071.html (Eberlein, 10 December 2016)
Tom; this has been on agenda for a while. what do we do with it?
Kris; this item will be on our agenda until Errata 02 goes out. Work includes 1) changes to the relevant spec source or grammar source, and 2) is it reflected in the Errata 02 document? I can take an AI for work on errata 02, I think for these, we need an associated wiki page.
**ActionItem; Kris will create a wiki page to track items to add to the Errata 02 document.
7. Continuing item: Formal work on DITA 2.0
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
Process:
Review of cards on project page
Backlog of random items
Stage one (in progress)
Tom; I'm looking at the backlog of items that need to be evaluated for 2.0, and would like to review each of them to see if we can either move it to stage 1, or delete it altogether.
[following items bracketed by -- -- are from the backlog list; description of item is followed by TC discussion and resolution of what to do with it]
--
TO BE REMOVED: Bringing consistency in the URI/Keyref format for referencing map elements & topic elements
--
Robert; this was about trying to have consistency between referencing map and topic elements. No one seems to be really interested in doing it.
Tom; is there anyone who has objections to make this item disappear?
Robert; I will remove it [done]
--
Remove the locktitle attribute from topichead and topicgroup
--
Robert; this is an artifact of the way locktitle was added; it's really a trivial cleanup item.
Kris; do we have a mechanism for handling trivial cleanup items like this?
Robert; it's trivial, but not backwards compatible, although as far as I now, almost no one's using it. I'll move it to stage 1.
--
Simplify keyref idea 1: Deprecate the rules for resolving keys which point directly to image files
--
Robert; I think we should delete this; the DITA 1.2 spec was badly written wrt imagea; in 1.3 this was clarified in a way that dealt with the core objection here. This objection was based on the 1.2 spec, which we fixed in 1.3 (the request came from Su-Laine originally)
Tom; objection? [none, item will be removed]
--
Simplify keyref idea 2: Deprecate the rules for displaying topicmeta in the key-defining element in the place of the keyref-bearing element
--
Robert; as i understand it, we shouldn't be transferring topicmeta between diff elements; the rules for handling that were massively cleaned up in 1.3., so this is really resolved by 1.3
Tom; any objections to removing this, [none, item will be removed]
--
Add keyref to category element
--
Kris; keyref was never enabled for the category element, we couldn't have made this change in the 1.3 timeframe; I consider it a bug fix in adding to an element'
Robert; I don't consider this a bug fix; it's adding a link to an element that doesn't have one.
Kris; we need to look at this with an eye to other metadata elements.
Robert; there's a workaround, and this requet also came in late; that's why it didn't get into 1.3.
Chris; it occurs to me that all of these elements can have conkeyref; is that sufficient for the purpose?
Robert; that's a possibility; for things like this, conkeyref is simpler and more logical.
Tom; so, do we need to assign a champion to it?
Robert; we just need someone who is interested in it.
Tom; so we don't need a champion now. If we move it to stage 1, should the card include a comment about conkeyref possibly being adequate?
Tom; is any one on the TC interesnted in being a champion? [no] OK, we'll move it into stage 1 without a champion. btw, what is the 'champion' status for the rest of the stage 1 items?
Robert; most of the stage 1 items have no champions yet; to go past stage 1, they will need champions.
Tom; so this item will go to stage 1
--
Allow domains to add elements to a specific context, rather than globally
--
Robert; don't remember much about this; there are cases where we'd like to do this, areas where adding a domain has been very frustrating; to some extent, this is addressed by including a specialized topic in a domain. Our DTD syntax has limited this; entities are a global thing. also a philosophical issue. We can't do it in a shareable module, so we disallowed it. We could say, 'if you want to do this, it would work, but you won't be in a reusable world'.
Tom; I wonder what Eliot's opinion of this would be...
Kris; this has a lot of merit, but I certainly won't champion it. We should think about whether this has value, and if so, who could possibly work on it. Do we need a category of 'this is a good idea, but do we have people who'll put in the work'?
Chris; do we need a group to discuss real changes to architecture, things that would require rewrites to grammar definitions and/or doctype shell content? We need to figure out what we cam do, and what we should do, in terms of major architectural changes, for 2.0.
Robert; one question for Eliot; if this is something that can easily be done in RNG, I'm all for doing it.
Tom; any objections [none;]
Kris; can we try to capture Chris's description of what it means on the 'card'?
Tom; i agree?
--
Add enumeration attribute to ol element
--
Kris; this came from George or Radu at SynchroSoft; we might want to go back to the original email from them.
Chris; this is for specifying a starting number of a first list item, I think it's a great idea, almost a bug fix.
[genl agreement]
Chris; put my name on it
Scott; also mine
[will go to stage 1 with Scott's name attached]
--
Correct glossref design WRT equivalent of print attribute
--
Robert; goes with the one above it, This had a defaulted print @, but a lot of people also hate glossref for other reasons. Changes are needed here. will anyone sign up
Scott; i'll sign up
[go to stage 1 with scott as champion]
Robert; this is also related to the general glossref design [see below]
Kris; let's move this item to stage 1; there's general agreement that it needs to be done. we just don't know a lot about it.
[will go to stage 1 with Scott's name attached]
--
Requirement for glossary design - how to support glossary related requirements
--
[see above]
Tom; we need to have Eliot look at this one.
Robert; we'll certainly not remove it without Eliot
[moved to stage 1]
---
Kris; can I add a card for new high-level design for 2.0 spec? We'll need changes to element ref topics as well as new high-level categories on how things should be characteristixed, e.g., 'processing', 'formatting'... Who is interested in working on this with me?
[Dawn, Carlos, Nancy, Robert, Kris, Chris}
Tom; should this be a stage 1 card? or an action item in the agenda?
Kris; I don't care how we handle it, as long as it can be easily tracked, and will have some actual written artifacts
Tom; we'll keep it on the agenda; once the group starts producing stuff, there might be more than one agenda item.
**ActionIteml; Kris will open discussion with the group of volunteers who are inteeerested in working on a new high-level design for the 2.0 spec.
8. Continuing item: Listening sessions
Portland, OR -- Rescheduled for January 2017?
Research Triangle Park, NC
Austin, TX
San Jose, CA: 21 February 2017
Nancy; Portland session is tomorrow.
Scott; will a dial-in be available?
Nancy; I'll try to arrange one.
================
Eric; would it be possible to add a discussion of bookmap to next week's agenda?
Kris; we can add it to the agenda as we usually do with items that come up from the dita-users list.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]