Groups - DITA TC Meeting Minutes 7 April 2020 uploaded

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

        Submitter's message
        ActionItems:
     None



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


Attendance:
Deb Bissantz, Carsten Brennecke, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Robert Anderson, Jim Tivy, Frank Wegmann 


Business
========

1. Roll call
        Regrets: none


2. Approve minutes from previous business meeting:
    24 March 2020
        https://lists.oasis-open.org/archives/dita/202003/msg00045.html (Harrison, 24 March 2020) 
Scott; need to add that I sent regrets
Nancy; will do
[will vote on these next week, after correction is made]


3. Announcements
TC was informed by Scott that sadly, Bob Thomas, after fighting a long battle with cancer, had passed away.  Kris will send a card on behalf of all the TC members.


4. Action items
[updates only; complete list is in agenda]
        28 January 2020
            Nancy: Respond to dita-users thread, with explanation of what SVG and mathML domains are for, to encourage more informed response 
- Nancy; this is in progress; it will go out to the list today
        24 March 2020:
            Kris: Update proposal deadline Wiki page COMPLETED 


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

Stage two

    (Zoe et al) Hardware control domain (https://github.com/oasis-tcs/dita/issues/257)
        Research being done 
- [agenda item #8 below]
    (Zoe) Remove machinery task and task requirements domain (https://github.com/oasis-tcs/dita/issues/350)
        ?: Proposal to reviewers 
- Kris; do you have a date for it going out to reviewers?
- Zoe; should be able to do that by end of week.
- Kris; so let's say next monday, 4/13.
- Zoe; I don't have a list of reviewers...
- Robert; for stage 2 you only need 1
- Kris; and since Robert and I plan to help with this, we can review it as well.

    (Carlos) New multimedia elements for base (https://github.com/oasis-tcs/dita/issues/351)
        ?: Proposal to reviewers 
- Carlos; I've started on this; it's going well, but I need a meeting with Kris.  This is opening a can of worms; revisions of multimedia domain impact topics shared between base and LwD, so it's taking some time.
- Kris; do we need Chris to join the call?
- Carlos; that would be better.
- Chris; send me an invite and I'll see if I can come.
- Kris; we can plan it at a time you're available.
- Carlos; for me, I'm available anytime during Weds.- Fri. this week.
- Kris; when do you think you can have the proposal to reviewers? 
- Carlos; in a couple of weeks; it bleeds into many things.
[will set for 2 weeks from today, 4/21]

    (Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
        ?: Proposal to reviewers 
- Kris; will have this ready for review 3 weeks from today.

    (Stevens) New diagnostic element for troubleshooting (https://github.com/oasis-tcs/dita/issues/316)
        14 January 2020 10 March 2020: Proposal to reviewers (Hudson, Harrison) 
- Dawn; let's move this to 4/28
- Kris; ok, just remember that our final date for all proposals to be completed is the end of June; I'd really like to get this one in.

    (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 --Completed by Frank Wegmann
        27 March 2020 23 March 2020 06 March 2020: Eberlein and Anderson to provide feedback 
- Chris; I'l try to get this out next week, even without Kris's review.
- Kris; thanks for lettimg me off the hook.

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; can we set next week 4/14 as the date for the new proposal to be ready for reviewers??
- Keith; OK.

    (Evia) Column/row spanning in simpletable (https://github.com/oasis-tcs/dita/issues/292)
        ?: Proposal to reviewers (Carsten, Anderson)
        31 March 2020: Initial TC discusssion 
[agenda item #7 below]


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
        Summary of DITA 2.0 triage
            https://lists.oasis-open.org/archives/dita/202003/msg00018.html (Eberlein, 10 March 2020)
            https://lists.oasis-open.org/archives/dita/202003/msg00032.html (Eberlein, 17 March 2020) 
        OASIS process for spec approval
            https://lists.oasis-open.org/archives/dita/202003/msg00033.html (Eberlein, 17 March 2020) 
[On hold until Kris has drafted expanded schedule ]


7. DITA 2.0 stage three proposals
        Vote
            None 
        Initial discussion
            #292 Expand simple table
                https://lists.oasis-open.org/archives/dita/202003/msg00048.html (Evia, 26 March 2020) 
- Carlos; the push for this came from a couple of goals. 
  1. make simpletable more compatible with HTML
  2. give an alternative to CALS that's stronger and more compatible with other systems.  It was reviewed by Robert and Carsten.  The
major changes are adding @s similar to the ones in HTML tables to allow for spanning, plus a title element; also, for accessibility, added headers and scope as @s.
- Carsten; the @s are all optional?
- Carlos; yes.
- Scott; there's also a @rowheader.
- Robert; that's been there since 1.0; we have keycol, which encompasses rowheader and more.
- Kris; I hadn't really understond that it impacts rowspans and choicetables and properties.  Should we be constraining those in the base?
- Robert; I wouldn't do that; people have done weird things with it. wrt choicetable, I'd be inclined to keep it. we could remove colspan, but I'd leave rowspan.
- Kris; I don't think decisions about constraining choicetable need to be made in context of approving this proposal.
- Robert; it would just be not adding the @ to those specialized elements.
- Kris; any other comments?
[none]


        Early feedback
            Response to Comments on "Feature #107 Add strong and em elements, and redefine b and i in a more semantic manner"
                https://lists.oasis-open.org/archives/dita/202003/msg00041.html (Schengili-Roberts, 23 March 2020) 
- Keith; one idea wrt b/i was to remove them where it appeared in legacy descriptions, so it wouldn't be carried forward to 2.0. I incorporated most comments, including one from Stan, but I also left out one of his, re; emphasis related to a lead-in (I couldn't find that). I also realized I shouldn't try to cover every possible way em can be used; possibilities are endless.  So I went after key ways in which em is used; I don't think we need to cover edge cases.
- Robert; we don't need to cover every edge case; we don't do that for other elements in the spec. 
- Kris; 2 comments; 
  1. elements that are being used for both 2.0 and LwD have been revised to incorporate both, and have been reviewed, so we have to be very careful about opening up those topics for another review.  
  2. The spec editors will keeping elements in alignment with 2.0, so we may not be using everything you have in your suggested reference topics; you have far more examples than we're putting in most topics. Are you suggesting that we make highlighting transitional, and suggesting they move from b/i to strong/em?   Calling bold/italic out as transitional suggests that they're 'old;' rather than 'new.'
- Keith; I just meant to show that they now have an option for moving from b/i to a more semantic usage. not implying that it's deprecated; just letting people know that if they want to move towards more semantic tagging, then b/i are transitional.
- Kris; none of my clients who already use b/i will move to strong/em. OTOH, new clients may very well use strong/em rather than b/i.
- Dawn; I agree; none of my clients will change, but new clients will adopt it.
- Robert; HTML has both em/strong and b/i; spec says 'if you have meaning, use these, otherwise use the other.'
- Keith; both sets will probably live there forever...
- Kris; I'd suggest, for the new topic for italic, just remove that paragraph.
- Keith; OK


8. Discussion of hardware control domain
        Feedback from dita-users? 
- Zoe; there was good feedback; i haven't done legwork to consolidate it; in general, people were in favor of something if it's simple.
- Scott; I've put some feelers out on this; still waiting; COVID has made it hard to get feedback from Boeing.  There was a proposal for markup for discrete and continuous operations; it could be handled with an @ to distinguish between the two.  It also needs a way to capture the value of what the control needs to set to.  And it also needs a part number; that was the early feedback I got; still waiting for more.
- Keith; there were several responses on groups.io; several liked being able to mark up keyboard compbinations; one wanted a 'gesture' @ for denoting gestures. There wasn't a lot of feedback on the idea of a distinction between continuous and discrete controls, 
- Kris; a lot of the feedback was 'yes; I want such a domain', but without a lot of details about what they want.  I asked for use cases and business requirements. One case was where they really needed different elements for hardware and software controls; they have both types and they translated hardware but not software controls.
- Keith; yes, I saw that
- Kris; Dawn, are your clients using outputclass now?  Would a simple hareware control element suffice, or do they need more?
- Dawn; haven't asked, but I think they would be happy with a very simple approach.
- Kris; one comment was 'I want more control over types of uicontrols', but wrt that, I think they can specialize their own.
- Dawn; I see this as only needing a single hardware control, not something more complex.
- Zoe; so is it better to just have a base control. or include a type @.
- Dawn; a type@ makes it easier, but we don't want to use name 'type'
- Zoe; agree, maybe @hardwaretype?
- Kris; our challenge for this domain is to come up with the simplest sort of proposal we can, but one that can be easily specialized.
- Zoe; I like the idea of having it be a stepping stone. 
- Nancy; I think that having a hardwaretype would make it easier to specialize.
- Keith; a question for Dawn - wrt the idea of having a part numbe; is that naturally part of the hardware domain?
- Dawn; we have clients who've done their own specializations; it was much more related to parts rather than switches or controls. If they have a part, they want a part number. That's much more for repair/replacement than for controls.
- Kris; I've done those kind of specializations for clients as well. One reminder; we can't add a new @ to domain elements; we have to use @outputclass.
- Robert; that's what @outputclass is for.
- Chris; if I can get to my proposal about loosening @ rules, it would gt easier to specialize @s.
- Robert; but this situation is just what @outputclass was designed for.
- Zoe; is it OK to put this into the description; 'if you want to be more precise about hardware controls, use @outputclass'?
- Chris; or if you have various classes of hardware, you'd want to specialize them.
- Kris; so back to hardware control domain; Scott, you think you'll get more feedback from Boeing?  I think we've heard a lot of feedback wanting a single hardware element. still trying to figure out if we need a part number child of hardware control.
- Zoe; not sure if it's a child
- Dawn; I agree; part number has a much larger scope
- Zoe; I agree also; I'd make it a ph specialization that could go anywhere. 
- Deb; what whould you specialize it from?
- Dawn; probably keyword or ph.
- Gershon; I would probably use keyword
- Kris; has anyone specialized a part number for anything other than hardware?
- Gershon; no
- Kris; so should hardware domain be just 2 items, control and part number?
- Gershon; part number shouldn't be in hardware control domain
- Nancy; we're talking about this as a hardware domain, not a hardware control domain.
[agreement]
- Zoe; what about something for swipe/gesture?
- Kris; I think we might want to consider that post-2.0.
- Zoe; gesture is something that's slightly 'hopping; a concept in new technology that we're not handling yet.
- Dawn; I've never heard a need for it, and I'd equate it to a actions like 'push' or 'select'.
- Gershon; and we don't have markup for using a mouse, and this is in the same ccategory.
- Zoe; the only time I've seen a gesture marked up is in an intro to 'using your new device'.
- Gershon; you could use userinput for that.
- Jim; what about having hyperlinks to captions in hardware diagrams?
- Kris; but base DITA already handles that.
- Jim; but should there be a designation for part in doing that?
- Kris; I think if we move ahead with this proposal, that would augment base DITA sufficiently.
- Jim; a part number element would definitely help.


12 noon ET close 

        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 7 April 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-04-07 20:42:19