| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 3 March 2020 uploaded
- From: Nancy Harrison<email@example.com>
- To: <firstname.lastname@example.org>
- Date: Mon, 9 Mar 2020 23:36:23 +0000 (UTC)
Minutes of the OASIS DITA TC
Tuesday, 3 March 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
Deb Bissantz, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Robert Anderson, Jim Tivy, Frank Wegmann
1. Roll call
Regrets: Dawn Stevens, Stan Doherty, Carsten Brennecke
2. Approve minutes from previous business meeting:
18 February 2020
https://lists.oasis-open.org/archives/dita/202002/msg00026.html (Harrison, 19 February 2020)
moved by Kris, 2nd by Gershon, approved by TC
Bill Burns has left TC as a result of leaving Healthline; also, Boeing members seem to have been deactivated, though Scott joined us on the call.
4. Action items
[updates only; see agenda for complete list]
03 December 2019
Gershon Joseph: Summarize previous discussions about #28: New publication map. Content in minutes and GitHub project card. COMPLETED
07 January 2020
Kris: Develop strawman schedule for DITA 2.0 work in 2020 In PROGRESS See agenda item #7
18 February 2020
Robert: Respond to Chris Trencamp about rules for nested conrefs within a conref push COMPLETED
Robert: Respond to Chris Trencamp about questions on "Key definition with key reference" COMPLETED
5. Review of DITA 2.0 proposal deadlines
(Nitchie) Add titlealts elements to map (https://github.com/oasis-tcs/dita/issues/16)
(./) 16 February 2019: New stage two proposal to reviews (Anderson, Eberlein, Frank Wegmann)
28 February 2020: Reviewers provide feedback to Nitchie
- Chris; I got feedback from Frank
- Robert; I'll try to do my feedback this week.
- Kris; And I'll do my best to do it also.
- Chris; just fyi, this weekend is the last weekend I'll have in March to work on this
[Kris & Robert will get their reviews done by Friday 3/6]
(Schengili-Roberts) Strong and em elements (https://github.com/oasis-tcs/dita/issues/107)
27 January 2020 25 February 2020: Proposal to reviewers (Doherty, Evia)
- Kris; thanks, Keith, for getting it out; Stan isn't on call; Carlos, do you have an ETA?
- Carlos; will commit to doing it this week, since next week is spring break.
- Kris; Robert; if you have a chance to ping Stan, that would be helpful, but we probably won't get info from him right now.
6. Continuing item: Prep work for developing a strawman schedule for DITA 2.0
https://lists.oasis-open.org/archives/dita/202002/msg00006.html (Eberlein, 04 February 2020
- Kris; we need to start with triage of existing proposals; I want to categorize them as 1) must have, 2) nice to have, 3) can fall of our plate, etc. See item #7 for details.
7. Review status of DITA 2.0 proposals in progress
- Kris; Chris, is 'New element for key text #345' required for 'Add titlealts elements to map #16'?
- Chris; I think so; they are either both in or neither.
- Kris, so #345 is a must have.
- Zoe; should we add labels to these cards
- Kris; how do we do that?
- Zoe; just go into the issue and add labels.
- Kris; Robert, please do that as we go over the items.
- Kris; wrt 'Hardware control domain #257' - I think this is somewhere between nice to have and could fall off plate
- Zoe; I agree.
- Chris; it was a valiant design effort, but it doesn't have to be in the standard.
- Kris; so shall we put it in 'can fall off'?
- Scott; I could see expandng the use of that, I kind of don't want it to drop off.
- Robert; I don't think this is deciding to drop things; but deciding whether it's gatekeeping for releae
- Kris; we need to be brutal; I'd like to have a summer date by which all proposals are done, and I'd like to have 'no new proposals' and 'stage 2 must be complete' dates fairly soon. For now, we'll put it in category 2, then a 2nd pass will show how much is in categories 1 and 2, and whether it can be done. How about that?
- Scott; sounds fair
[gen'l agreement to this in TC]
- Kris; what about new new diagnostic elements; I think they're 'nice to have', but work might not be done in time, so category 2.
- Gershon; could this be added to a later release?
- Scott; we have a pressing need for this, but we can go with column 2...
- Kris; what about #33 'deprecate or remove copy-to'; I think it's somewhere between nice to have and 'fall off plate'.
- Eliot; it's just waiting for me to rewrite an example section.
- Robert; it has to be treated as nice-to-have, but we've talked about it so much that it would be embarrassing not to do, and if we can't do it in 2.0, we can't do it till 3.0.
- Gershon; I agree.
- Kris; so we'll put it in must-have category for now. What about release mgmt domain usage? didn't we decide to handle this a different way?
- Robert; it went into bookmap
- Kris; so we can remove it from here.
- Kris; What about new title-less topic?
- Eliot; that was Dawn ann me, but there's been no progress.
- Kris; we could put it in nice to have, but it needs to be in category 3, so we don't have to think about resource allocation.
- Kris; now let's look at stage 1 items. Wrt 're-design grammar files'; that's done for DITA base, it just needs to be done for techcontent. It doesn't really fit here as a proposal; it's just spec work that has to be that has to be done on grammar files. Let's move that out of a card, and figure out how we track it for techcomm package.
- Robert; I'm worried if we delete the card, it will just be forgotten.
- Kris; so don't delete the card, but we need to figure out how to track it not on a card; we want to winnow this list.
- Kris; what about '"Normal if used" value for processing role attribute'? It probably needs to go in category 3.
- Kris; Wrt 'make schemeref more generally available in maps #163'; that
came out of subjectscheme issues. We'd like to have changes to SS, but it's too much work; this should be a 3.
- Gershon; this is our only chance to make backward-incompatible changes before 3.0; it would be a huge effort, but it's an opportunity to revamp things to make them more usable.
- Kris; but if we don't have a quick resource to fully do that design work in 3 mos, we don't have a choice.
- Gershon; if Robert and/or Eliot could help, I'd be willing to drive it.
- Kris; I think you're not realizing the complexity.
- Gershon; we're suffering from the complexity. it's a problem for us; it's really getting in the say of author productivity.
- Kris; we'll leave it in 2 for now, but I do urge people to be brutal...
- Gershon; put it in 2 and give it to me; if I can get #28 done, I'll do it.
- Chris; if a new approach to SS is desired, it's not something we can't do in 2.x; it could be something new that could be added later.
- Gershon; so then we'd have old and new stuff running in parallel.
- Kris; but that's a good point Chris; given how problemmatic SS is, let's move on.
- Kris; Eliot, once you have room, will you be able to do 'Modifications to image for metadata, alternate image references #97'?
- Eliot; I'd like it to be a must have, but it will have to be a 2.
- Kris; and it may fall to 3, if you don't have time.
- Robert; this is one I would like to help with; we can't call it a must have, but it's important.
- Kris; ok, we'll have it in 2.
- Kris; What about 'Generic universal attribute for metadata #96'? I think it's a 3.
- Kris; Next, 'separate machinery task from technical content'. I think the idea was to drop machinerytask from 2.0, there's no one on TC with the domain expertise.
- Robert; but people still use this.
- Kris; so they can use the 1.3 version, or one that we gin up to go with 2.0, but we have no domain expertise to work with it, so we shouldn't be pushing it forward to 2.0.
- Kris; I think the effort of bundling it for a separate package is less than keeping it in the base at 2.0.
- Robert; but even just that is a lot of work.
- Scott; as an add-on module, that should be fine; I don't think it should be in the base.
- Kris; it's definitely not base, but it might be in techcomm. Also, when I talk about deadlines, I'm thinking base and techcomm; but in fact, techcomm could be later.
- Nancy; so are we going to take this out completely?
- Kris; yes.
- Robert; but this is technically a backwards incompatible change; so we need a real statement about it in the spec.
- Kris; you're right; it requires a proposal so we can track the changes; the lack of an owner is why it's in stage one.
- Robert; I would own this if I were eligible to, and I should be able to own it soon..
- Kris; can anyone wlse own it.?
- Kris; What about 'Mandate a processing order #30'? I think this is closest to being a must do.
- Robert; I'm not sure; it's really a giant can of worms, and if we don't do it, we really can't do it till 3.0.
- Chris; I'm very interested, but too busy. Robert, Eliot, Jarno and I have to get in a room and argue it out.
- Eliot; I've been a champion for doing it, but it's a real technical challenge, and not sure it can be done in time. Maybe once Robert is fully reinstated, we can put our heads together....
- Gershon; if enough of us are at DITA/NA, we could lock ourselves in a room and work on it??
- Eliot; I probably won't be there this year.
- Kris; so, do we put it in 2.0?
- Eliot; an explanation of the issue needs to be there, if we can't put it in 1 and do the work.
- Chris; I think punting, and acknowledging the ambiguity, may be the path of least resistance.
- Eliot; It's not entirely ambiguous, but yeah, some of it is.
- Robert; that's right.
- Kris; What about 'Clarify what characters are allowed in keyscope attribute #9' It was opened by me, and it seems more like a spec fix than a proposal..
- Robert; yes, I agree.
- Kris; it's not something to be put in a category, really just a spec bug fix.
- Kris; Eliot: What about 'Change the name of the locktitle attribute to something less ambiguous, and change default to "yes"? For now, I'm hoping we could handle as part of #16. What do you think?
- Eliot; I'm trying to remember the details of this one.
- Kris; #16 is 'add alttitles'...
- Eliot; can this be pulled into titlealts?
- Robert; Chris; does your proposal address thsi
- Chris; yes, locktitle goes away.
- Kris; so this proposal also goes away...
- Kris; Keith, what about 'Deprecate type="fastpath" attribute value for note elements #35'?
- Keith; I think we can get rid of this, and I also don't think it would take long to do. What's the next step that needs to be done for this? a stage 2 proposal?
- Kris; if you want to take ownwership, we'd would need a stage 2 proposal
- Keith; the importance is it's a backwards comapatibility issue, but it's not a critical item; it can fall off the plate, but if i have time, I'll put in a stage 2 proposal for it.
- Carlos; just a thought, if we keep pushing things to stage 2, it will make it hard to adopt those things in LwD, because it will add more conditional processing for LwD to the spec.
- Kris; I haven't seen anything I'd be concerned about yet.
- Robert; this one in particular, wouldn't have any impact on LwD, but we shoud vote to move it to stage 2.
- Keith; and I could do it
- Kris; then we'll move to stage 2. TC neds to approve moving it. I so move.
[Eliot 2nd, approved by TC]
- Kris; What about 'improve gloss support'? It's a laudable goal, but no one wants to own it.
- Scott; we were facing glossary problems; we needed it to be easier to incorporate terms; I don't know it that's glossary or a DITA-OT issue...
- Eliot; my proposal was motivated by the goal of making one part of glossary easier..
- Scott; your presentation at last year's conference was one piece of this enhancement request.
- Eliot; I would do it if I had time...
- Kris; so improved glossary support has to go to 3 unless we have a champion... and we may have to move 2s to 3 next week.
- Kris; Scott, what about 'Add enumeration attribute to ol element'?
- Scott; it can probably fall off; it's not as critical as many others.
- Kris; and it's not a backwards-incompatibility issue, it could be added later.
- Kris; let's go through the BACKLOG items: What about 'Allow domains to add elements to a specific context, rather than globally'? Can this easily be done in RNG? Should it be part of broader DTD / RNG changes?
- Robert; there's not much more behind this than gen'l request...
- Kris; so probably a 3
- Eliot; there's a way, but not straightforward.
- Kris; wo, what to do about this?
- Eliot; it has to be a nice to have,
- Kris; or a 3?
- Eliot; one of those things, if we don't explicitly allow it and people do it, it won't break anything. I don't wan't to add an editorial 'not' to the spec...
- Robert; patterns in DTD get really ugly; it could be easier in RNG, but it would still take resource we don't have....
12 noon ET close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]