Bill Burns and I would like to applaud Nancy for all her hard work taking minutes all the time. She makes it look easy. 10 Sept 2019 TC Call Action Items No new items this week Minutes of the OASIS DITA TC Tuesday, September 10, 2019 Recorded by Zoë Lawson and Bill Burns Link to Agenda for the meeting: TBD (Still on main page at the time of writing) Attendees: Zoe Lawson Kris Eberlein Bill Burns Robert Anderson Stan Doherty Eliot Kimber Chris Nitchie Joyce Lam Carsten Brennecke Scott Hudson Jim Tivy Jacquie Samuels Business 1. Roll call 2. Approve minutes from previous meeting No minutes had been posted to wiki by 10 AM, so none to approve. 3. Announcements none 4. Action Items Let's skip action items until later (and we ran out of time) 5. Stage 2 proposals Issue #252: Add outputclass to DITAVAL flagging properties Robert Anderson (RA): DITAVAL has flagging, but limited set of styles. Let's add outputclass to make things 'just work' with CSS like other elements. If an element is flagged with something managed by a ditaval, that element will get the outputclass defined in the ditaval. If there are multiple values from different flags, outputclass takes more than one value already Elliot Kimber (EK): Seems good RA: Idea came from Jarno. Obvious in hindsight. Kris Eberlein (KE): Opens up new possibilities for @rev. No effect on CMS that don't support ditaval. RA: only impact on tools that already support ditavals and flagging. KE: comments/questions Scott Hudson: Like it, useful Stan Doherty: Agree. KE: reviewed proposal. Good, useful. Make sure there are real world usecases and examples. Although that's hard at stage 2 RA: if not familiar with flagging, doesn't seem useful. But if you're familiar with flagging, it's useful. KE: Conference session on flagging? RA: Voting on this next week? KE: Most likely. Any objections? Hearing none, this proposal will be voted on next week. Request for feedback Issue #64, "hazardsymbol and the redesign of the hazard statement domain" KE: Redesign of hazardsymbol domain. Issues with where the hazard symbol is permitted. Look at
https://lists.oasis-open.org/archives/dita/201909/msg00016.html (apologies for the spaces) Each hazardstatement can have 1 or more hazardsymbol ; one or more messagepanel hazardsymbol is not associated with messagepanel Current model works fine with 1 panel, one symbol. When you get many to one or many to many...it gets confusing. Does this image associated with the hazard, or the howtoavoid? [Kris reitterates the information in msg00016.html] Also, better reuse. We have concrete examples where current implementation doesn't work. - If there are multiple images with specific messagepanel To the council <hazardsymbol> with <messagepanel> or with the children? What about keeping it with hazardstatement? we can break back compatability. EK: need hazardsymbol with messagepanel definitely. Do we have to restrict to child or parent? could we use both? KE: it's easy to have the children add one or more hazardsymbol. Don't have to do more refactoring. If hazardsymbol is part of messagepanel as peer to howtoavoid etc, then have to change sepecialzation base. messagepanel specialized from list. child items are list items. EK: Odd KE: This is from dita 1.0 because no div. RA: Specialization base is wrong. EK: Agree RA: Having this information diplay as Lists by default seems wrong. Looked weird. EK: hazardsymbol should be with children of messagepanel. (RA: yup) KE: Confirming that hazardsymbol is not associating with the generic symbols caution/warning/danger EK: First example (in msg00016.html) makes less sense. KE: Bad example to try and work from. That Warning symbol isn't necessary. EK: Go to next example. As a writer, makes more sense KE: Couple of options: 1) regardless, change specialization (everything a div) - may cause havoc on default rendering. Not that we can't, but we should be aware (rendering/author/output) probably should RA: Agree. EK: default is better in html KE: 2) where put hazard symbol a) just messagepanel b) just children c) everywhere, EK: Must be allowed in children. otherwise, messagepanel needs attribute to assign to appropriate children. KE: reuse easier EK: natural grouping KE: if also allowed in message panel (for simpler cases), better for migration. Scriptable. then could finetune later. EK: makes sense. Sad no amber or john today. RA: but based on responses should work. Scott Hudson: if do the both option, should accomodate all the use cases from Boeing. also like div proposal. KE: by supporting both, should support Jung's requests. should cover all bases. I need stage 2 reviewers. should be quick turn around. Will also pull in Jung and Amber. Scott Hudson volunteers. Assuming Amber will want to. Hoping for next week. [Following notes are from Bill Burns] Zoe: We’re at a point where we need to determine where this new element goes. The original idea was to put it in the software domain, but this doesn’t feel warm and fuzzy. On the other hand, we don’t want a domain with only one element. Does someone else have an idea? Do we need a hardware domain? Whatever else would go in it? Maybe hazardstatement? Eliot: Software domain still feels right for this as most of the use cases will be keyboard operated. Kris: Amber has mentioned the need for something like this element for some time. Robert: Is this element intended to meet both use cases: a key on a keyboard and a button on hardware? Scott Hudson: I’ve seen others—pilot controls. Toggle a radio button or whatever control it may be. Eliot: UI domain exists. This seems like it would go into it but should be a specialization of the existing uicontrol element. (description of uicontrol). That seems to be the right specialization base. Might want to distinguish among button, switch, glider? Kris: This might create a dependency on the UI domain that some might not consider appropriate. Eliot: They’re wrong. No difference between a key on a keyboard or a physical button pressed, just a difference in implementation. Stan Doherty: Often in virtual environments, the hardware is running through software. This distinctions aren’t as clear. Scott Hudson: Or use cases where you have to press a hardware button and keyboard key simultaneously, e.g. pressing Shift+Reload to force a browser to reload. Kris: Would we slot this in software or UI control? Eliot: There’s no precedent for a domain with multiple levels of specialization. Kris: We don’t need to assume that this new element would be based on uicontrol. We can edit and recraft short descriptions for these. None of these elements have been touched for about 20 years. Robert: How many of us were using touchscreen elements back then? Everything is a ui now, just different types of buttons. Eliot: I want separate elements for buttons or other things that are part of a UI. Zoe: I appreciate that perspective as these objects are anything through which a user interacts with a device (computer, phone, other). The assumption seems to have been that these are interactions with software. This needs to be reconsidered to include hardware objects. Eliot: Maybe we should start over with ui domain. Robert: It was developed with the idea that we’re interacting with something on a screen, which is not as easy to assume these days. The uicontrol description does cover all of these things but we could have something for all of these objects based on uicontrol. Eliot: Maybe “pressable” objects… Zoe: I’m a bit scared to consider tag for swipe left. Eliot: A swipe control. Based on discussion so far, a separate button domain makes sense. Robert: Button is way too generic. Zoe: But do we change ui domain? Eliot: A separate button domain implies a closed set. Specialization of uidomain seems to make most sense. Looking at uicontrol, one challenge is that it’s too generic, it conflates two different kinds of things. Compare it to JavaSwing controls. Menu items are a type of button. Entry fields are a different kind of thing. They share no common superclass. Kris: Have most of us found uicontrol to be inadequate? General agreement: yes Zoe: To play devil’s advocate, we’re trying to get rid of the chocolate-chip cookie problem—overuse of semantic tagging. We’re cutting down on semantic tagging to avoid over styling. Is semantic tagging over used? Why try to convince people to tag when there’s no clear immediate benefit to them? Eliot: No one indexes anymore. Kris: This discussion doesn’t help Zoe with her limited use case. Do we move ahead with the limited use case for things to press and look separately at having a broader effort for uidomain. We need more discussion on this.