Submitter's message ActionItems:
1. Robert will add @cope element to anything that currently doesn't have it.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 10 November 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas Attendance:
Robert Anderson, Carsten Brennecke, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Dawn Stevens, Frank Wegmann, Jim Tivy
Business
========
1. Roll call
Regrets: Deb Bissantz, Stan Doherty
2. Approve minutes from previous business meeting:
03 November 2020
https://lists.oasis-open.org/archives/dita/202011/msg00017.html (Harrison, 07 November 2020)
moved by Kris, 2nd by Gershon, approved by TC
3. Announcements - None
4. Action items
28 May 2019:
Chris Kris: Look at draft-comment in spec WD03, section 8.2.2.19, page 210 IN PROGRESS
18 June 2019
Robert/Kris: Work on remaining stylesheet issues; see
https://wiki.oasis-open.org/dita/stylesheetBacklog . IN PROGRESS
07 January 2020
Kris: Develop strawman schedule for DITA 2.0 work in 2020 In PROGRESS
25 August 2020
Carlos: Develop review schedule for !LwDITA spec
03 November 2020
Deb, Scott, Dawn, Gershon, Stan, Eric: Post markup using resourceid to the list COMPLETED by Deb, Scott, and Stan
- Kris; can Dawn, Gershon, and Eric please complete this? thx...
5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business discussed]
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 Stage two
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
03 November 2020: Initial discussion by TC
- Kris; Eliot, do you think you've gotten enough examples to move forward?
- Eliot; I haven;'t looked at them yet, but they're probably sufficient.
(Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
- Kris; I got feedback from all reviewers; this is on agenda [item #8] to clarify issue around abbreviated-form element.
Stage three
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
(Nitchie) Add title alts to map (https://github.com/oasis-tcs/dita/issues/16)
- Kris; Chris, any news on when we might see either one of the above proposals?
- Chris; I made some progress on titlealts one, not next week but probably week after...
- Kris; what about reviewers?
- Chris; not sure who they are...
[Kris, Frank, Robert have volunteered to review]
7. Consistency issue with linking attributes
https://lists.oasis-open.org/archives/dita/202011/msg00013.html (Anderson, 05 November 2020)
Agreement from Eberlein, Kimber, Nitchie
https://lists.oasis-open.org/archives/dita/202011/msg00016.html (Anderson, 05 November 20200
- Robert; looking at the new features for media elements, noticed they didn't include @scope. It's how we distinguish between something that's already accessible, that will be there, or that will not be accessible from your info. In 1.3, we said every element that has an href needs a @scope, but it got missed for audio and video. For consistency, we should add it to them, plus add it to anything else that has href but doesn't have it, including a part of hazardstatement, and svgref.
- Kris; anyone have objections?
[none]
- Kris; so does this go under 'open github issues for cleanup work'?
- Robert; I don't think so; that category is for checking for backwards incompatible changes, this won't be one of those. I think it's really just a bug fix.
***ActionItem; Robert will add @scope element to anything that should have it but is currently missing it.
8. DITA 2.0 stage two proposals
Early feedback
#345 New element for resolving variable text
Issue #345 and the abbreviated-form element
https://lists.oasis-open.org/archives/dita/202011/msg00025.html (Eberlein, 10 November 2020)
https://lists.oasis-open.org/archives/dita/202011/msg00027.html (Kimber, 10 November 2020)
- Kris; variable-text starts with a ref to abbreviated-form; since it's not in base, I left it out in new proposal. But we need to account for it somehow. Chris suggested a series of options, then Robert suggested we treat 1.3 rules as rendering expectations, rather than rules. The 1.3 description is a bit complicated, depending on where it occurs, but we don't define what 'where' is. any thoughts?
- Chris; abbreviated-form is different from any other keyref. We should add to your proposal, to include a mention on what to do about elements that are specialized, and provide some way that specializations can do stuff without them being the same as variable-text. Another option is to get rid of abbreviated-form, because it's a mess... Robert suggested we treat it all as rendering expectations. but when I see rendering expectations, it means stylesheet authors have to be able to control it; and keys and keyrefs aren't easy to do that on in a processor. It strikes me more of a developer task to do that, rather than a stylesheet author.
- Scott; I don't want to get rid of abbreviated-form; we've used that a lot, the capability is expected in user community.
- Kris; the problem is we put this wonky processing expectation for abbreviated-form in the spec at 1.2, and have normative language about it that includes mention of 'intro' and 'non-intro' context, but we don't define in spec what intro/non-intro context is.
- Robert; but, OTOH, there's no requiresment that something in a rendering expectation has to be done by a stylesheet author rather than a processor developer.
- Kris; I agree with that.
- Robert; this element is a mess, but a lot of people have a requirement for it, and we never cleaned it up. I don't have a problem with leaving 'intro/non-intro context' undefined - there's no way for us to define that - but the implementation is gross, whereever it happens. I like the idea that this isn't a big exception; it can be an element outside of base with a non-normative recommendation.
- Chris; if we create a special specialization, then we've set up a process that makes it impossible for a processor to satisfy all flavors of keydef.
- Jim; right.
- Robert; there is no requirement that if you specify your own linktext, that's what ends up on the screen; we can do that, if only because of translation. It's an oddity to code that into rendering expectations, but we cant prevent it.
- Chris; but treating this as a rendering expectation. you might not resolve it at rendering stage.
- Eliot; I've often changed the way that things that are refs to other things actually display. knowing that that is a workaround; as an engineer you have to implement your system so it can be achieved. You have to resolve keys in the early stage of processing; there's no way you can't make that info available downstream.
- Robert; that's how it was done in DITA-OT when this was implemented.
- Chris; there are implementations out there for which that will pose a challenge...
- Kris; I think it would be bound to be ugly, it just is.
- Robert; if they're doing it today, whatever they're doing will probably work tomorrow...
- Chris; ok
- Kris; anyone still have concerns will treating abbreviated-form as rendering expectations, rather than rules? they can't be normative rules.
[no objections]
- Kris; I will update #345 and we'll review it next week.
9. DITA 2.0 stage three proposals
[no updates]
10. Direct Links In a CCMS environment
https://lists.oasis-open.org/archives/dita/202011/msg00023.html (Tivy, 09 November 2020)
https://lists.oasis-open.org/archives/dita/202011/msg00026.html (Kimber, 10 November 2020)
[Jim explained his concern, and there was then a general discussion on his request for a non-keys, direct way of addressing content that is available in a CCMS, but that from the rules of DITA can't be reliably addresed without the use of keys. Eliot pointed out the issues with this suggestion, and reiterated the point made in his email response, which was that in DITA, the only way to do what Jim is asking for reliably, if there is any reuse at all, is by using keys. He noted that a processing engine could use a simpler business-rule-based mechanism if there were never any reuse of content, but for any reuse to be available (not sure why an organization would bother with DITA if there was never any reuse...), keys are the only reliable method.]
[refer to the email exchange for more details]
12 noon ET close
-- Ms. Nancy Harrison Document Name : DITA TC Meeting Minutes 10 November 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-11-10 14:02:32