[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from 10 September 2019
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]