dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 27 October 2020 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Sat, 31 Oct 2020 02:23:59 +0000 (UTC)
Submitter's message
ActionItems:
1. Kris will put proposal 15 'loosen @ rules' on agenda for next week.
2. Kris will schedule call with Chris and Robert on interaction between proposals #16 and #345.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 27 October 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy
Business
========
1. Roll call
Regrets: Deb Bissantz
2. Approve minutes from previous business meeting:
20 October 2020
https://lists.oasis-open.org/archives/dita/202010/msg00045.html (Harrison, 20 October 2020)
moved by Kris, 2nd by Scott, approved by TC
3. Announcements: none
4. Action items
[no updates; see agenda for complete list]
5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business]
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
[updates only; see link above for complete list]
Stage two
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
[agenda item 8a below]
(Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
Kris; started working on this, on agenda today
[agenda item 8b below]
Stage three
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
- Chris; discussion between me and reviewers is at an impasse, we may need a wider discussion.
- Kris; should it come back to the TC to deal with the impasse?
- Chris; sure
- Kris; I'll put it on agenda for discussion for next week.
***ActionItem: Kris will put proposal 15 'loosen @ rules' on agenda for next week
7. Return of the fastpath
https://lists.oasis-open.org/archives/dita/202010/msg00046.html (Anderson, 22 October 2020)
- Robert; TomM suggested getting rid of this early in 2.0; we queried sources and couldn't find any usage, so we approved a stage 2 proposal. Then, someone mentioned that they wanted it, and cleaning it up has little practical benefit, so I think it should stay in, and we just ignore it from now on.
- Keith; I originally brought this forward, but if someone's actually using this, then I'm fine with leaving it.
- Frank; I know the user in question; I might be tempted to approach them and see if it's something he really wants, but that would mean postponing it another week.
- Robert; I don't think it's worth it; there's no particular benefit in removing it; we just didn't think anyone was using it, and the person using it is, in fact, using it as intended.
- Kris; I second that, so we'll withdraw this proposal and close the door on it.
- Robert; I'll update the ticket.
8. DITA 2.0 stage two proposals
Initial discussion
a. Issue #33 Remove copy-to
https://lists.oasis-open.org/archives/dita/202010/msg00058.html (Kimber, 26 October 2020)
[postponed to next week; discussion of #345 took more time than expected]
Early feedback
b. Issue #345: New element for defining variable text
https://lists.oasis-open.org/archives/dita/202010/msg00052.html (Eberlein, 26 October 2020)
- Kris; This came out of development for issue #16 'Add to map'. As it went to stage 3, Chris uncovered technical issues. Issue #16 was returned to stage 3 and issue #345 was added to cover the new element for defining variable text and revised rules for determining effective text content. Issue #345 was reviewed by Robert and the guts were also reviewed by Chris. There are common use cases when users need alternativee ways to define link text. Given those, I defined a new keytext element, which has a subset of the content model for linktext / ph, for example, it doesn't include img. The new element zeros in on semantics that people use for that kind of thing.
- Dawn; I have a lot of clients who use images for key linktext, so I'm not sure about removing it.
- Kris; that's an excellent point. The proposal isn't just about keys to reference images, but it doesn't permit images in the content model; we do have people using variable text for images
- Robert; for images, key text is alttext.
- Scott; what about superscript and subscript?
- Eliot; one thing about ph is, once you have ph, you can put in anything, including img. The intent is that we're trying to avoid people putting img in keytext, but since ph is allowed, we can't really prevent it, e.g., using img to reference picture of glyphs; or text might have inline images that function as characters.
- Kris; it would be helpful to me to get clarification on that, but first I want to go thru rest of proposal. So keytext will be optional child of topicmeta in map, can occur only once in a map, and will take univ-atts. The other part is redefining our current rules for processing text content. It's a simplicfication of rules (see the proposal for specifics).
- Eliot; on first read, I like this a lot, it makes sense on how to do it
- Chris; I agree.
- Kris; so, for migration, we are disallowing a markup pattern that was commonly used in 1.2 and 1.3 [see proposal]. For migration, if you have that pattern, you need to migrate to use either the new keytext element, or linktext, as appropriate. It will hit users, but it should be fairly doable without much pain. In return, we get much cleaner markup.
- Carlos; I agree it will make things easier, but I'll have to update the LwD map, since it uses the old way.
- Kris; wrt the examples, I think they're important. For example 3, we have best practices for using keytext, navtitle, linktext, so as to keep them separate.
- Robert; I wanted this as an example because this is the one potential point of confusion. If you're making a link, you might think it was linktext, but it will be keytext. Basically, if an element can take an href, you resolve text one way, if not, it's another way.
- Chris; another way to explain it is to use keytext when the element is the source of the text, linktext is for empty elements, where it's the target of the link rather than the source of the link.
- Robert; and a best practice; when defining a key, don't put both keytext and linktext in there.
- Chris; what about when putting a key on a normal topicref?
- Scott; if it's something that should be avoided, we shouldn't put it in an example...
- Robert; we need it here, to show what not to do.
- Chris; also, the spec is meant for implementors, and they need to see it.
- Scott; what about translation variants, if you wanted to put them all in one place?
- Kris; don't do it; it's a warped edge case, would have to do conditional processing to make it work.
- Robert; or dp it using some edge case way; it's not within scope of this proposal.
- Kris; now that we've walked thru this, are you comfortable with it? It doesn't disallow keys to be images.
- Dawn; yes, I'm OK with it.
- Chris; it does illustrate the overlap between this and titlealts proposal. It makes this complicated because the fallback for spec is cu. if inheritance order is different for 2 items, can't have what you have for this example.
- Kris; I know what I'm proposing differs from your stage 2 proposal, which calls for keytext to be part of an alternative title domain. I say we must have keytext as a base element, but only available in maps, not topics. Did your proposal require removal of linktext and replacement with linktitle?
- Chris; yes, but since it's my linktext, it's different from this. Also, needing to be able to reorder things made me think they needed to be independent of order.
- Robert; I'm not sure they need to be in a specific order.
- Chris; but currently, topicmeta is an ordered list. in my proposal, it needs to be replace with *. Being able to put keytext in anywhere messes up the content model.
- Robert; I think it could come in a particular place, in an order, without a problem.
- Kris; we don't have to have that particular order.
- Chris; my concern related to migration; I'd like migration to just be replacing one tag with onather; if we have this in a particular order, it could be a problem.
- Kris; listening to your proposal, I'm hearing another migration issue, and it could be a big issue.
- Chris; maybe I no longer need to do that. in current stage 2 proposal, keytext is in there, I needed to pull linktext in to make * work. We can talk about whether linktext goes away.
- Robert; I share Chris's discomfort with have a specialized element be a fallback for a base behavior.
- Chris; the reason I pulled linktext in, was because navtitle and searchtitle would both become possible, and in current content model, linktext appears betwen those 2 elements. titlealt carries a mandatory @titlerole. So fallback behavior for linktext, would be to fall back to alttitle whose role includes linking, but could be any alttitle that specifies linking. if we don't make a change from linktext to linktitle. I don't like linktitle to be different elements in map and topic. But if we don't do that, we have ordering issues in migration.
- Kris; l'll set up a call to discuss how these interact.; please look at part that mentions common use cases. Please think about your client's use cases. Do you have examples of this, maybe ideas for a DITA Adoption white paper? What are your use cases for variable text? Please post to list if you have more use cases.
- Kris; I'm glad this had early feedback. clearly needs a lot of rework. Chris, will you be available for a call to discuss these issues?
- Chris; yes
- Kris; any others?
- Robert; probably me
- Kris; anyone else?
[none]
***ActionItem; Kris will schedule call with Chris and Robert on interaction between proposals #16 and #345.
- Kris; Currently Chris and Carsten will be stage 2 reviewers, next step is getting formal proposal to them. any other reviewers?
[Dawn, Frank will also review.]
- Kris; good, this is an important proposal; the more eyes, the better. Any other comments or questions. [none]
9. DITA 2.0 stage three proposals
Vote
Remove data-about
https://lists.oasis-open.org/archives/dita/202010/msg00030.html (Anderson, 15 October 2020)
Robert moved, 2nd Keith
Voting result:
yes votes 15 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann)
no votes 0
- Kris; just fyi, Simon Bates uses data-about, but he didn't chime in on dita-users, and we couldn't figure out how to describe the element in the spec.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]