Groups - DITA TC Meeting Minutes 17 March 2020 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItems:
   none


=================================================
Minutes of the OASIS DITA TC
Tuesday, 17 March 2020
Recorded by Hancy Harrison
link to agenda for this meeting:	
https://wiki.OASIS-open.org/dita/PreviousAgendas

Attendance:
Deb Bissantz, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Robert Anderson, Frank Wegmann 


Business
========

1. Roll call
        Regrets:  Eliot Kimber, Stan Doherty  


2. Approve minutes from previous business meeting:
        103 March 2020
            https://lists.oasis-open.org/archives/dita/202003/msg00021.html (Hudson, 10 March 2020) 
moved by Kris, 2nd by Zoe, approved by TC


3. Announcements
	none


4. Action items
[updates only; see agenda for complete list]
        18 February 2020
            Carlos: Look at LwDITA element reference topics for 2-3 elements and document -- IN ANY FORMAT -- the MDITA and HDITA content that is missing
- Carlos; we should remove this AI; I will have to do the work in regular DITA repo; I don't need to do a show and tell; working with Mark Giffin on this.
- Kris; I'd actually be very interested in a show and tell
- Carlos; give me a couple of weeks on it.


5. Review of DITA 2.0 proposal deadlines
        https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 

Stage two
    (Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
        (./) Due 05 October 2019
        (./) 08 October 2019: Initial discussion by TC
        On hold for new version: Vote by TC 
- Kris; we haven't heard back from Eliot

    (Schengili-Roberts) Remove fastpath value from @type on image (need issue and reviewers)
        (./) 16 March 2020: Reviewers to provide feedback (Doherty, Lawson, Frank Wegmann) 
- Kris; do we have a new date?
- Keith, probably next week; also, change 'image' in title of this item  to 'note'
- Kris; ok
- Keith; I don't think there's anything for me to do; the reviewers all ok'd it.
- Kris; are you ready to present today?
- Keith; don't see why not...

    (Evia) Column/row spanning in simpletable (https://github.com/oasis-tcs/dita/issues/292)
        ?: Proposal to reviewers (Carsten, Anderson) 
- Carlos; I'll try for this week.
- Kris; so we'll update this to list you getting it to reviewers by next Tues. 3/24

Stage three
    (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; will this be ready for TC consideration by next week?
- Keith; yes, I got reviews from Stan, Carlos, Scott


6. Suggested DITA 2.0 dates
        https://lists.oasis-open.org/archives/dita/202003/msg00020.html (Eberlein, 10 March 2020) 
[from Kris]
     - No new proposals/no revision to existing proposals: 1 April March 2020
     - All proposals completed: 30 June 2020
- Keith; that seems fair to me
- Zoe; what does 'all proposals complete' mean? thru stage 3?
- Kris; yes; that gives everyone 3 months to get proposals thru the pipeline.
- Zoe; fine with that..
- Kris; We really want to release in 2021, se we have to get everything into OASIS pipeline by a year from now; we'll have a lot of review to do after all proposals are complete.  If need be, we could have 2-4 weeks slippage, but don't count on it.
[TC voted to commit to the above dates]

Voting results:
yes		9 (Deb Bissantz, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts)
no		0

[Anumber of TC members voted 'yes, with reservations', but were willing to commit for now.]
- Kris; I realize this is aggressive, but we're already behind; 2020 would have been a better date, since it's 5 years after 1.3.


7. 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
       NEW: Summary of DITA 2.0 triage
            https://lists.oasis-open.org/archives/dita/202003/msg00018.html (Eberlein, 10 March 2020) 
        UPDATED: https://lists.oasis-open.org/archives/dita/202003/msg00032.html (Eberlein, 17 March 2020) 
- Kris; please look at the updated table; the last 2 items on it could be done, but could also be done in a subsequent point release, since they wouldn't create any backwards-incompatibility.  Take a look at OASIS requirements for passing a standard; it takes at least 6 months from our completion/voting date to jump thru OASIS hoops. 


8. DITA 2.0 stage one proposals
        Early feedback
            New map for publications in base #28
                https://lists.oasis-open.org/archives/dita/202002/msg00027.html (Joseph, 24 February 2020) 
- Gershon; I went thru 2-3 years of history on this, as well as all the work on #29 (the legacy bookmap update). The intent is to creat a new pubs map that is structured and sound; it doesn't need to support every possible output. We want to fix problems with apps and parts. We also had a lot of requests to fix problems using reltables, which I think we should replace with something specific to this map; that way, we can remove overloading of topicref.  We'd like the ability to publish one or more articles.  I'd like to leverage RNG best practices for creating the grammar files and constraints; they're currently now based on the DTD models, which produces headaches.  I want to do a new structuring of grammar files, something slightly different, if the TC doesn't like what I've proposed, we might have to have more discussions. I'm willing to take this on and drive it. The time frame for 2.0 is aggressive, but I think it can be done; if it can't, then we can do it for post-2.0.
- Robert; are you intending to address all the cases you mentioned?
- Gershon; these and some more esoteric ones that were recorded in TC minutes.
- Robert; what you're proposing seems huge to me; I have no problem with you trying, but it seems such a huge change.  You seem to be assuming DTD is normative, but RNG has been normative since 1.3. OTOH, the RNG patterns are set up to allow our specs; I don't think a grand change to how we structure RNG/DTD files should be part of this proposal.
- Gershon; bookmap doesn't abide by everything already. we could use Eliot's d4p specialization as part of the base; once I have new RNG files in place, I can start playing with constraints with that. 
- Kris; I echo Robert's concern. Anything you're suggesting that really affects how we structure RNG grammar files would have to be part of another proposal.
- Gershon; OK, my main purpose is to come up with a new publication map
- Robert; what do you mean by 'a grammar that doesn't really work'?  Our patterns enable what we need.  If you want to suggest a way to have the grammars work, it really can't be part of this proposal.
- Kris; can you give us an example of 'patterns that don't really work'?
- Gershon; e.g., if you want to constrain li to only contain p, you can't do that an eary way. 
- Robert; we have examples of this in the spec; look at those. I don't know why you would have to change those patterns. 
- Gershon; I talked to Eliot; he didn't have a suggestion that would help us.
- Robert; we have a topic in the spec about how to use constraints.
- Kris; what are the primary use cases for your new pub map, and what are the primary features of your proposal?  As a TC, we talked repeatedly about this, we never had a consensus on what should have been in it. we thought that d4p was too complex for us.
- Gershon; my understanding is that we want a bookmap that doesn't have some of the limitations of current bookmap, e.g. even the name 'bookmap' is a problem; reltables are a problem, We need to create a replacement for topicref there.
- Robert; reltable is also something else that's beyond changing in a publications map; it's part of the base map, so if it's going to be changed, it has to be considered separately; changing it would be hugely impactful. 
- Chris; there are lot of things in bookmap that are problematic because of bookmap, but grammar files and reltables are problematic  because of the nature of maps; we can't make changes to them without making chhanges for all of DITA.  We'd need to carefully scope those changes.
- Gershon; I think #29 is already doing that
- Kris; #29 is already doing that, we were going to fix what we could in bookmap, but not break back-compatibility.
- Gershon; there's not much difference between the rest of what I was doing and #29.  If we can't do major things, then it's better to just go with #29 and leave it at that.
- Kris; we'll keep this in the backlog; if you want to make proposals about reltables or grammar files, there's a short window to make those proposals.


9. DITA 2.0 stage two proposals
        Vote
            None 
        Initial discussion
            None 
        Early feedback
           Remove fastpath
               https://lists.oasis-open.org/archives/dita/202003/msg00017.html (Schengili-Roberts, 10 March 2020 
- Keith; basically, fastpath is rarely used; there was a question posted to yahoo dita-users asking if people did use this, and it got a minimal response.
- Kris; questions or comments?
[none; vote next week to move to stage 3]

            Remove machinery task and task requirements domain
                https://lists.oasis-open.org/archives/dita/202003/msg00024.html (Lawson, 17 March 2020) 
- Zoe; so the idea is that we don't have the tech expertise in TC to maintain this any more. It's basically a specialized topic and a domain with a bunch of elements, so we're basically trying to rip it out. It seems to be just a doc shell and the task-requirements domain; Robert gave my proposal a cursory review.
- Robert; yes, it's a pretty straightforward change, and yes, it's because we can't maintain it.
- Kris; we want to be clear about our plan to make it available in a Github repo for folks, or are there changes we'll have to make to it in order to have it be compatible with 2.0?
- Robert; there are some fairly minor changes needed, as long as its no longer in the standard.
- Kris; and we also need to consider what sort of messaging we want to provide to people wrt this, and I can help with that.
- Zoe; thanks, since that messaging is important, and I only have vague guesses.


            Hardware domain
                https://lists.oasis-open.org/archives/dita/202003/msg00025.html (Lawson, 17 March 2020) 
    A Systematic Way to Describe Non-Computer Controls (Relating to "Hardware Control Domain")
        https://lists.oasis-open.org/archives/dita/202002/msg00010.html (Schengili-Roberts, 05 February 2020)
- Zoe; in the past, we had a couple of discussions on this.  We decided that trying to define all the things you can press/touch/twiddle was too much, so chose to just provide as single element you can specialize, i.e., a hardware control.  There was a request to also provide a partnumber, which should be an element rather than an @.  So the original proposal included both hardware control and part number elements.  Then Keith noted that there are 2 basic types of hardeware controls; one with specific states, that is, a discrete control, and another type that can be more fluid. I don't know whether we should create a domain with both types of control, and the part number, or if we should have a single hardware control element, which we then specialize into discrete-control and continuous-control (or something like those names).  Or do we want a single hardware control, with @s to specify which kind of control it is?  I need more help with what actual content models should be.
- Kris; we've had this on the agenda for awhile.   Keith, can you give us an overview of your email, and your thoughts about specialization?
- Keith; I think Zoe nicely captured my distinction between discrete and continuous controls.  When I was working on converting pilot's manuals, there were lots of buttons and switches that didn't fit neatly into the uicontrol paradigm.  If we need an element for hardware control, but don't want to have @s, then we can just go with 1 element for continuous, and one for discrete, controls.  Wrt a part number, that's a different thing; a part number is a static description of something.  I can see use cases for an element, but I'd need to understand why you would want to distinguish such a thing.
- Kris; does anyone remember what use case was for a part number?
- Scott; if you do callouts or an exploded diagram, it would be useful to identify items by part number.  But for human readable info, you need a hardware control name and a setting, and for translation, those need to be elements not @s.  Otoh, a part number could be an @.
- Zoe; there was also an idea that if you're documenting a hardware control, the part no could be a child of the hardware-control element. 
- Scott; but if you're doing a maintenance procedure, you need an ID for a part, the part number isn't just for hardware-control.   You need a separate part element, as distinct from the hardware control element(s).
- Chris;  I'm getting a bit of whiplash here, if we don't have the espertise to maintain the machinery task, why are we discussing hardware controls?
- Nancy; the idea is that we're taking out a machinery task that's more complex than we understand, but we do understand enough to realize that we need something, though much simpler, to replace it.
- Scott; I agree with that.
- Chris; if we try to pull it down to least common denominator, we'll be stuck with it.  So I'm willing if you have confidence in that. but I'm not sure about it myself.
- Scott; I think it's workable.
[to be continued]


12 noon ET close 
        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 17 March 2020

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2020-03-21 20:10:52