OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]