dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 29 March 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Tue, 29 Mar 2022 18:24:07 +0000 (UTC)
Submitter's message
ActionItems: none
=================================================
Minutes of the OASIS DITA TC
Tuesday, 29 March 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Dawn Stevens, Frank Wegmann, Jim Tivy
Business
========
1. Roll call
Regrets: Carsten Brennecke, Scott Hudson
2. Approve minutes from previous business meeting:
22 March 2022
X (Joseph and Harrison, X March 2022)
3. Announcements
none
4. Action items
[updates only; see agenda for complete list]
16 November 2021:
Gershon: Talk to Precision Content dev team about developing tool to generate contains/contains content
- Gershon; we're probably not going to be able to do this now; the team is under a lot of pressure and working flat out. we should probably remove this for now.
- Kris; we'll do that.
15 March 2022
Robert: Create GitHub card for the new proposal to add an attribute to cover cascading of roles COMPLETED
5. Quarterly check-in: How are folks doing?
- Kris; spec editing is both rewarding and draining; no new review ready this week. Would love to hear if anyone has thought about ways we can do this better; e.g. if we had more of a schedule for what we're reviewing when, or assigned reviewers?
- Eliot; for me, it's generally better to have assigned schedule.
- Kris; pls think about how this can work better.
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
[updates only; see link for complete list]
Stage two
(Eberlein) Remove classification domain and add new attribute (https://github.com/oasis-tcs/dita/issues/647)
(./) 07 March 2022: Submit to reviews (Brennecke, Joseph)
(./) 09-13 March 2022: Feedback provided by TC and external reviewers (Pam Noreault, Ellucian; Shane Taylor, Cengage)
(./) 22 March 2022: TC discussion
29 March 2022: TC discussion
?: Vote by TC
- Kris; this is back on agenda (item #7) for discussion today.
(Anderson) Add new attribute (X)
?: Submit to reviewers (Brennecke, Joseph)
?: Feedback provided by reviewers
?: TC discussion
?: Vote by TC
- Kris; we need to add github issue.
- Robert; will try to get work on it done this week.
- Kris; but priority for this is below that for spec editing.
7. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
Remove classification domain and add new element
https://lists.oasis-open.org/archives/dita/202203/msg00040.html (Eberlein, 29 March 2022)
- Kris; finished an updated stage 2 proposal; the 2 main issues are:
1. what elements should @subjectrefs apply to? Currently applies to ALL topicref elements and specializations of topicref (base and techcomm)
2. where do we want to say @subjectrefs has no meaning?
- Kris; Current proposal says ?The @subjectrefs attribute has no meaning if it is specified on a key definition that does not reference a resource.? This covers variable text, but permits using @subjectrefs on non-DITA resources, such as PDFs, and it also now enables setting @subjectrefs on key definitions that reference images. We can decide later on applicability. This affects many elements in bookmap that are specializations of topicref; I don't think @subjectrefs applies to most, but they do contain @href, and applying @subjectrefs to them does make maintenance of grammar files easier. Robert and Eliot supported this; any comments?
- Eliot; supportive of changes
- Robert; also agree
- Kris; any concerns?
- Eliot; so far, can't think of any
[will vote on this next week]
8. Content and timing for next review
- Kris; we were hoping we'd have conditional processing open by Friday, but it just needs more work before we can have a productive review. We also have open items on today's agenda that apply to it. e.g. passthrough token and filtering/flagging. So we want to open a review later this week on something else; it might be a small one, maybe content around translation and L10N. That material hasn't been revised much since 1.2, and there are some topics that were dumped in 1.2 that are not good for 2.0; e.g., some feedback we got from the OASIS TAB (technical advisory board) was about sections not being numbered, which, while we successfully pushed back on langref topics, does need to be done for arch spec topics.
- Robert; that L10N stuff is not pretty, needed more scrubbing than we had realized.
- Kris; with legacy content, we're dealing with a decade plus of spec terminology. e.g., with xml-lang, which is taken from XML and doesn't cascade, even though in DITA it's a metadata element, and those generally cascade. So the editing is messy; hopefully we'll have a small review, might be ready Weds. or Fri. but we don't know for sure.
9. Feedback on dita-comment
mapref does not allow ditavalref (and can this be supported in DITA 2.0?)
https://lists.oasis-open.org/archives/dita/202203/msg00028.html (Chris Papademetrious, forwarded by Eberlein, 21 March 2022)
- Kris; his question is "why can't you apply a ditavalref to mapref, even though it can be applied for topicref?" We have feedback for this,
- Dawn; I would like to hear guidance on this as well, it's always seemed a bit weird.
- Robert; the reason is because of the way that domains work; when we create a specialization of topicref, the specialized element can show up anywhere you can put a topicref. But by design, it doesn't show up in mapref, because mapref doesn't allow nested topicrefs. If we were to allow it there, it would require it in all mapgroups, and would require much messier constraints for most use cases.
- Eliot; and it's not that it doesn't make sense, it's just the content model complexity it introduces. At any rate, if you really want one, you can create your own specialization.
- Kris; do we need more discussion? if so, let's hold it over till next week.
- Zoe; that explanation is perfectly clear, but where would I find it?
- Robert; that's not something that can be explained in the spec.
- Zoe; I wouldn't want to find it in the spec, but is there somewhere it could be found? Is that something we want to do?
- Kris; you're raising great questions. we'll put this back on agenda for next week.
10. Usage of passthrough token in DITAVAL elements
https://lists.oasis-open.org/archives/dita/202203/msg00034.html (Anderson, 22 March 2022)
https://lists.oasis-open.org/archives/dita/202203/msg00035.html (Kimber, 22 March 2022)
[skipped for today; on agenda next week]
11. Examples and use cases for filtering and flagging
https://lists.oasis-open.org/archives/dita/202203/msg00032.html (Eberlein, 22 March 2022)
- Kris; for 2.0, we really want to get better examples, real-world, clear, aimed not just at implementers but some general users. As we worked on cond, processing content, for most part I added new examples for real-world use cases for flagging, but I didn't have much for filtering. We really need to get that material from other TC folks.
- Dawn; I have a lot of different use cases for filtering
o between different versions
o by audience, e.g. different countires with diff regulartory requirements, or filtering for internal/external use.
- Zoe; we have examples of filtering by feature, and install/upgrade guides filter by differences between sizes of upgrade, e.g., a complete new release vs. patch or upgrade; these are not simple examples, but definitely real-world.
- Kris; it's always challenging to find an example that's both real-world but not overly complicated.
- Stan; we're having discussions around global filtering vs user-specific filtering, writers having control over their publications. Once we've figured it out, it would be an interesting example.
- Kris; talking about global vs branch filtering; that's an important issue, and I hadn't thought about it. My advice has always been to keep filtering as simple as possible. Thinking ahead about filtering design can mitigate issues. but for a really big organization, global vs writer-specific filtering is relevant.
- Gershon; we try to avoid conditional processing and use keys instead; we've started reducing our dependence on conditional processing as much as possible.
- Kris; for product names, or for variable text?
- Gershon; we haven't needed to go back to filtering/flagging since we started using keys.
- Dawn; I generally agree with Gershon; one of my clients has an incredible mess of conditional files, we want them to go with keys instead. Conditional processing is definitely often abused, but there are still real-world use cases for it.
- Robert; conditions can only be replaced with keys on a ph, not a p.
- Kris; same thing, ph or variable text.
- Eliot; you can get mileage out of using conkeyref instead of conditional text. pushing conditionality up to map level.
- Zoe; but you can't push it up to whether something exists or doesn't exist
- Dawn; right, the thing is to use conditions if something exists or doen't exist, but use keys if content always exists but is just different across versions.
- Kris; we have complexity because DITA contains so many subtleties and spec can't reflect everything.
- Eliot; it's a real challenge to understand and apply correctly.
[to be continued]
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]