Groups - DITA TC Meeting Minutes 28 January 2020 uploaded

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

        Submitter's message
        ActionItems:  
1. Nancy will respond to dita-users email thread on SVG, with explanation of what SVG and mathML domains are for, to encourage more informed response.
2. Kris will explain why hazardstatement is in base
3. Kris will look into what we need to do to move forward with addition of draft-comment to remedy in troubleshooting topic.


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



Attendance:
Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Eliot Kimber, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Robert Anderson, Frank Wegmann 


Business
========

1. Roll call
        Regrets:  Deb Bissantz, Gershon Joseph


2. Approve minutes from previous business meeting:
   21 January 2020
      https://lists.oasis-open.org/archives/dita/202001/msg00031.html (Harrison, 27 January 2020) 
moved by Kris, 2nd by Scott, approved by TC 


3. Action items
[updated items only - see agenda for complete list]
        09 April 2019
            Nancy: Does SVG zip file need to be in techcomm grammar folder? IN PROGRESS 
[on agenda today]
        28 May 2019: 
            Chris Kris: Look at draft-comment in spec WD03, section 8.2.2.19, page 210 IN PROGRESS 
[on agenda today]
        18 June 2019
            Robert/Kris/Bill: Work on remaining stylesheet issues; see https://wiki.oasis-open.org/dita/stylesheetBacklog . Stylesheet walkthrough scheduled for Friday, 31 January 2020 at 1 PM ET. IN PROGRESS 
        21 January 2020
            Kris: Ping Dawn about her stage two proposal COMPLETED
            Kris: Update DITA 2.0 Proposals page COMPLETED 

[discussion following #5 applies to #4 & #5]
4. Attempt to boil down the

and proposal discussion
https://lists.oasis-open.org/archives/dita/201912/msg00034.html (Nitchie, 10 December 2019)
https://lists.oasis-open.org/archives/dita/202001/msg00001.html (Kimber, 04 January 2020)

5. Continuing discussion of issue 16: alternate titles
https://lists.oasis-open.org/archives/dita/202001/msg00029.html (Nitchie, 25 January 2020)
https://lists.oasis-open.org/archives/dita/202001/msg00030.html (Burns, 27 Janaury 2020)

- Chris; item #5 is my attempmt to respond to item #4. one proposal out there that's actually 2 things; i.e., titlealts, and keydef configuration. The fact is that they really are 2 different things. Most of the email traffic pertains to the first, titlealts. Currently we have possible elements that can all be alternate titles. The discussion is around which do we really want, and how should they be structured, which should take precedence, etc. But it seems to me that in an attempt to reduce complexity, we're adding complexity. My email of 25 Jan is an attempt to fix that. I think that by making alternate title available through navtitle, it serves the purpose of all alternate titles by default. For the simple case, navtitle is your alternate title. I would like feedback on this; I want to table for now the discussion on keys and linktext issue. So this proposal is to have titlealt with a @title-role and with navtitle as the only speciiializetion. [see 25 Jan email for details]. So default token is put on item's navtitle element; you specify navtitle and it just works, while still allowing specific alternate title cases.
- Eliot; there's always a concern when we have a multi-value default, but this seems to be OK.
- Chris; it does create some conversion/migration issues; now navtitle exists, but not searchtitles; suggest we get rid of titlealts, and put it in prolog;
- Eliot; if you really care about searchtitles, it's easy to add it back in. I don't think migration cost is too bad.
- Kris; I'm a little confused; you want to table talking about whatever element serves purpose of linktext; but are you suggesting that people would used navtitle for their linktext value?
- Chris; I'd be open to a separate element, maybe keytext, OTOH, if you don't have a keytext, but you do have a navtitle, most authors would expect navtitle to be used for that purpose.
- Kris; most authors, if they're creating a key def to hold variable text, would they expect it to be called navtitle?
- Chris, OTOH, if they were creating something and not specifying it, they would expect navtitle to be used.
- Robert; in writing the 1.2 spec, one of the most painful parts, we tried to draw a line so key defs that went somewhere were treated one way, and if they didn't go somewhere, they were treated another way; it would be nice to have just one way...
- Chris; I'd want a second specialization of keytext, but if thet wasn't present, and navtitle was, then navtitle would be used as default.
- Kris; I'll buy that, but since 1.2, I've been working with authors to tell them they can use keytext to create keys for images. defining variable text in navtitle e.lement? any one have comments?
- Chris; what is the concern, with keydefs to images in general, or with how you specify alt text for images?
- Kris; for users, defining keys is complicated. Even to use a topicref to define a keydef for an image, that's painful for people, So having navtitle to hold variable text, I know there are some issues with using key definitions.
- Chris; I've found the same, but many people who aren't developers struggle with indirection in general, and there's nothing we can do about that. All we can do is give good examples, good training materials, and good trainers. But we can't make the problem go away.
- Kris; we can guard against introducing add'l complexity, but no one else seems to share my concern, so I won't continue it. Any other concerns?
[none]
- Chris; I wanted to make sure this would fly, since it seems so, now I'll start over with stage 2; will pare it down and leave out keys. The proposal with note that keys will be handled somewhere else.
- Nancy; in that case, the proposal will need to specify where we're going to put that discussion.
- Chris; can we create a new stage 1 proposal for a description of that? But that proposal should be done after this proposal.
- Kris; OK



6. Action item: Does SVG zip file need to be in techcomm grammar folder?
Harrison posted on DITA-users: https://groups.io/g/dita-users/message/45091 (21 January 2020)
Eberlein forwarded one e-mail to the list: https://lists.oasis-open.org/archives/dita/202001/msg00027.html (24 January 2020)
- Nancy; I sent out mail and got back opinions on both sides; my sense is that many users don't really understand what it means to use the svg or mathML domains. You don't need them to simply include an SVG image or an equation; you only need them if you're going to programmatically construct or alter such things.
- Stan; we heard confusion about SVG and mathML domains at listening sessions; the Adoption TC has an AI to write a white paper on the topic, but haven't gotten to it yet.
- Kris; has anyone had time to look at the thread on dita-users? It's clear that people don't understand what the domains are for and why they might be used. Lot's of people use SVG images, and think that means using the domain. It would be interesting to see who is using SVG domain and for what.
- Nancy; I've used it when I had to have an SVG image be output at an exact size, regardless of the variable size of the original images.
- Stan; I've had to use it in badging, also when something has to be the same size every time.
- Kris; looks like we could definitely improve our description of the SVG and mathML domains in the spec, and why someone might want to use it. One of the responses also asked why hazardstatementdomain is in base; we did that because of its use in marketing.
- Robert; we've had it come up; if we suggest moving it out of base, there's always someone who strenuously objects.
***ActionItem; Nancy will respond to email thread on SVG, with explanation of what SVG and mathML domains are for, to encourage more informed response.
***ActionItem Kris will explain why hazardstatement is in base
- Kris; I encourage people to take a look at this thread. People are using it more; my sense is the new infrastructure is working well for people. There were a lot more posts in January than there were in previous years at this time.


7. Action item: draft-comment element in troubleshooting topic
https://lists.oasis-open.org/archives/dita/202001/msg00033.html (Eberlein, 28 January 2020)
- Kris; this AI was Gershon's, but I've been working on a lot of troubleshooting topics, so I thought I'd take a crack at it [see her mail] Seems to me the only place we might want to allow it, where it isn't available. is in remedy. We might want to put in an optional draft-comment, before or after responsibleparty. Any thoughts?
- Eliot; a bit concerned about adding draft-comment to rememdy directly; it doesn't really fit, Since it's already available in all the sub-elements, it doesn't seem that compelling.
- Kris; I wouldn't have suggested it, if rememdy didn't already contain an element that's specialized from p.
- Eliot; where in remedy would you put it?
- Kris; I thought it could be either before or after responsibleparty; I don't think it would matter which.
- Eliot; and draft-comment would apply to entire remedy element?
- Kris; yes
- Eliot; well, that works from a content model viewpoint. As an author, I wouldn't be likely to putting a draft-comment in either remedy or reponsibleparty.
- Frank; peple put draft-comment all over the place, Maybe you've put more thought into it than most authors, so I'd put a draft-comment in remedy as well.
- Kris; if yu try to put it somewhere in remedy, editors will try to make you put it in title, I am not wedded to this; we can leave it hanging if there are real objections.
- Eliot; not really, I don't have any real problem with putting it where you've suggested.
- Kris; any other thoughts / comments?
[none]
- Scott; I agree with your suggestion.
- Kris; any other thoughts? Robert, do you remember how we're handling extension of draft-comment in other places? as a bug fix?
- Robert; I don't remember, it could be a bug fix...
- Kris; I'd like to handle this the same way, but I can't remember either.
- Kris; so are we OK with adding it? any objections?
[none]
***ActionItem: Kris will look into what we need to do to move forward with this.


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

Stage two
(Stevens) New diagnostic element for troubleshooting (https://github.com/oasis-tcs/dita/issues/316)
14 January 2020: Proposal to reviewers (Hudson, Harrison)
- Kris; Dawn, can you update the date?
- Dawn; I've sent a note to Bob Thomas; what's holding me up is technical stuff, and he's the best resouce on this. But I haven't heard back fro him, and Brianna is with me and would also be a good resource, but she's busy too. I'll try to contact him again when I get back on 2/14
- Kris; how about beginning of March?
- Dawn; so March 10th?
- Kris; fine

Stage three
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
TBD

(Nitchie) Add titlealts elements to map (https://github.com/oasis-tcs/dita/issues/16)
10 December 2019: Revised stage two proposal to TC
- Kris; what should be the new date?
- Chris; 3/11
[reviewers: Robert, Frank]


(Schengili-Roberts) Strong and em elements (https://github.com/oasis-tcs/dita/issues/107)
27 January 2020: Proposal to reviewers (Doherty, Evia)
- Kris; have you seen the proposal, Stan or Carlos?
- Stan; no
- Kris; I'll email Keith and see what's happening


- Kris; Stan; did you get to schedule a meeting with Scott and Deb about glossaries?
- Stan; no, not yet



11:50 ET close


-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 28 January 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-01-28 10:05:49