Groups - DITA TC Meeting Minutes 17 September 2019 uploaded

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

        Submitter's message
        ActionItems: no new items


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


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Kris Eberlein, Carlos Evia, Joyce Lam, Hancy Harrison, Scott Hudson, Eliot Kimber,  Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens 


Business
========

1. Roll call
        Regrets: Stan Doherty, Eric Sirois 


2. Approve minutes from previous business meeting:
        03 September 2019
            https://lists.oasis-open.org/archives/dita/201909/msg00056.html (Harrison, 17 September 2019)
                https://lists.oasis-open.org/archives/dita/201909/msg00060.html (Correction by Eberlein, 17 September 2019) 
Kris moved, 2nd by Carsten, approved by TC
        10 September 2019
            https://lists.oasis-open.org/archives/dita/201909/msg00043.html (Lawson and Burns, 15 September 2019) 
Kris moved, 2nd by Carsten, approved by TC


3. Announcements:
        None 


4. Action items
[no specific updates; see link to agenda for list of current items]
- Scott; not on action item list, but I issued proposal #297 for discussion.
- Kris; sorry, I overlooked it; I thought it was just going for reviewers, but I can fix that.
- Scott; it didn't have formal reviewers assigned
- Kris; so you want general feedback; we'll cover that.


5. New item: Additional change to hazard statement domain?
        https://lists.oasis-open.org/archives/dita/201909/msg00047.html (Hudson, 16 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00048.html (Eberlein, 16 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00049.html (Hudson, 16 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00051.html (Eberlein, 16 September 2019) 
- Scott; The important point is to allow those elements in any order, so wrt a need for a directive at start of messagepanel, don't think that's a requirement.
- Kris; right, the current content model calls for starting messagepanel with 'typeofhazard.' 
- Scott; I think a directive can be within howtoavoid; my suggestions are to ensure we can also align with ASD-STE 100.
- Kris; I do think your concerns are covered by current proposal.
- Scott; agreed, if we need a specific order, I can do it in my shell.
- Kris; actually, you can't do it in the shell, you can only do it in the rendering.
- Robert; your stylesheet could force howtoavoid to come before consequence.
- Kris; so we can go forward with #164.



6. DITA 2.0 stage two proposals
        Vote
            Issue #252: Add outputclass to DITAVAL flagging properties
                https://lists.oasis-open.org/archives/dita/201909/msg00012.html (Anderson, 04 September 2019) 
Robert moved to advance this to stage 3, 2nd by Scott
Voting results:
yes votes:		13 (Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber,  Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens)
no votes:		0
[reviewers for stage 3 will be Eliot and Scott.]

        Continuing discussion
            None 
        Initial discussion
            Issue #164: Redesign hazardstatement
                https://lists.oasis-open.org/archives/dita/201909/msg00058.html (Eberlein, 17 September 2019) 
- Kris; I appreciate the early feedback I've gotten on this; it was reviewed at stage 2 by Robert, Scott, and Eliot.  I also sent it to Jang and Amber, and got approval from Jang.  This was done to make it more compliant with ANSI Z535.6, and involves restricting elements, expanding contents of messagepanel and howtoavoid, changing the specialization base of messagepanel and its child elements, and finally removing hazardsymbol as a direct child of  hazardstatement.  That last part is backwards incompatible, but should be a fairly simple migration.
Questions? comments? objections?
- Scott; I'm satisfied.
[vote next week]

        Early feedback
           Issue #297: Allow example element in more places 
    https://lists.oasis-open.org/archives/dita/201909/msg00036.html (Hudson, 11 September 2019) 
- Scott; we want to enable having example available in more contexts, so we can have add'l semantics for content in different locations; we'll allow example everywhere fig can go, except no nesting.  Currently there's tag abuse because of its limitations, and we'd rather have better semantic markup.  Making it into an optionally titled block, and having it everywhere fig is allowed, shouldn't add difficulty in rendering, but it adds more locations where example can be added. This shouldn't be backwards incompatible, and there's no change to content model for example.  At this point, I'd welcome add'l feedback, and I need revieres so I can finalize the proposal.
- Robert; I think this is a complete stage 2 proposal
[Joyce and Carlos will review.]
- Kris; I also effectively gave a review last week, so pls use my comments as well. 


7. DITA 2.0 stage three proposals
        Vote
            None 
        Initial discussion
            Issue 34: Remove topicset and topicsetref
                https://lists.oasis-open.org/archives/dita/201909/msg00042.html (Kimber, 15 September 2019) 
- Eliot; they've been there since 1.2, no one ever used them, so we decided to remove them; get rid of them and just use topicref as you would anyway.
- Kris; one minor tweak on page 5, in table for migrating content. for topicset, just missing file extension on @href value.
- Eliot; topicset defines a topicset, doesn't need the extension.
- Robert; think in table one should be there is formatting; in topicsetref, should have hashtag.
- Eliot; I copied this directly from 1.2 spec
- Robert; shows how little anyone has looked at this
- Kris; so need to make changes to 2.0 spec
- Eliot; to see the correct formatting of the incorrect examples, have to look at HTML rather than PDF.
- Kris; making a plug for using official - i.e., HTML - versions :-)
- Robert; an FOP issue with code that runs over the cell.
- Eliot; I'll correct it.
- Robert; for topicsetref, where did you copy the example from?
- Eliot; 1.3 spec
- Robert; I don't see that in errata02...
- Kris; I want to make sure we have good migration content in the proposal;  we publish these proposals and other folks harvest content from them.  When working on proposals, pls ensure your content is a match with whatever you sent to TC for approval. make sure source in SVN matches what you send to TC.
[vote on this next week, with changes we made in formatting]


8. Continuing item: Things you press
        https://lists.oasis-open.org/archives/dita/201909/msg00019.html (Lawson, 09 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00020.html (Kimber, 09 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00033.html (Hudson, 10 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00028.html (Anderson, 10 September 2019)
            https://lists.oasis-open.org/archives/dita/201909/msg00046.html (Bissantz, 16 September 2019) 

9. New item: Reviewing user interface domain
        https://lists.oasis-open.org/archives/dita/201909/msg00044.html (Lawson, 16 September 2019) 

[following discussion began as agenda item #8 and moved into #9]

- Deb; I have medical device content where there are tools controlled by foot pedals, pedals have multiple different functions, but we have no elements to identify descriptions of such functions.  We also have dials to adjust to various settings; similar to Scott's situation. 
- Kris; issue is, what's an appropriate element to specializa from when describing different physical controls?  Do we need a new base element to be a speialization base?
- Zoe; this is why I'm thinking of a user interface domain to include physical controls; do we want one or more new specialization bases; maybe a 'thing you press' is too little and we need to go bigger.
- Kris; both agenda items are deeply related.
- Scott; whether it's software or hardware, calling it user interface; I need to identify not only the control, but the setting for that control, dial or flap.  I think we can abstract it out, but we need a combo control, e.g., "force reload: hold shift key and click reload." How do we identify software vs. hardware, and combinations?
- Zoe; is it as simple as a label and value, or do we need something more, and could it be used for both hardware and software? But we need to have both gui controls and phpysical controls.
- Scott; and there's also the question of actions; e.g., a swipe vs. a shake...
- Eliot; a question I'd ask is 'what's the value of having a common specialization base?  Is it for SEO? formatting? common content models? or to capture a core semantic?  It's clear there's some commonality, but is there also a compelling reason to have a single base tag?  There's quite a range in sophistication from a button on a panel to an aircraft control. so in an airport cockpit domain, you need a lot more specificity.  Does that domain and gen'l user domain need to have common specialization base?
- Deb; from my perspective, a lot of people don't know how to specialize, and don't have confidence around specializing.  So being able to provide, for most [novice] adopters who want to specialize, a way to distinguish between 'here's the thing I do something on' and 'here's what I have to do with it', would help a lot of adopters.
- Eliot; this motivates a need for these domains, but it doesn't say whether they need a common underpinning.  If it's a req to say 'find me all kinds of interactive controls', then having a base type would be very handy.  If that's not a req, then it doesn't matter.  Or if they have a common formatting. right now keyword element is the base for all ui and sfw controls.
- Kris; ph is there also.
- Eliot; but keyword is the base for any named thing, then specialization shows what the actual name is.
- Kris; so I would find it more helpful if we have a base element from which we could specialize to get Deb's 'foot pedal'.  When I think of a foot pedal, I have to choose between keyword and defining 'footpedal', though that's what I would use.
- Nancy; we defined uicontrols for sfw, so we need an analog for physical controls; we've already gone down that road for sfw, and hardware is not software.
- Eliot; we are starting to recognize between real-world controls and their virtual equivalent, but it is the same control trying to perform the same type of action
- Zoe; then there is also the case of the combo switch where you have (for example) keyboard plus some additional action; a hardware domain does not make sense, but we need to have something that account for working with physical objects
- Eliot; need to be aware that interaction is already used in the L&T specialization
- Kris; maybe we should explore a hardware domain, what would be the generic things it would contain? What use cases would this address? Should we post this question to DITA users? Suspect that there may be a bunch of cases where hardware and software do not overlap.   Where do we want to go with this? Do we expand the ui domain, and/or do we make a new hardware domain?
- Zoe; I don't want to move forward on "the thing you press" yet, as I think we need to solve the bigger issue first as to where these types of things belong.
- Robert; agreed in general with the proposal that uicontrol should encompass all things in this context
- Dawn; disagree, I'd emphasize that it is a hardware interaction, often in-practice involving an outputclass to show a distinction between a software interaction and a hardware interaction.
- Zoe; actions might be another way to look at things, where you might shake, tilt, tap or do other actions to an object.
- Kris; what's the relevance of prelreqs within the machinery task topic in this context?
- Scott; there is no combo element for when multiple things are invoked at once, such as Ctrl, Alt, Delete as one action
[to be continued]


12 noon ET close

        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 17 September 2019

---

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: 2019-09-19 11:13:42