dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 22 March 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Tue, 29 Mar 2022 18:22:03 +0000 (UTC)
Submitter's message
ActionItems: none
=================================================
Minutes of the OASIS DITA TC
Tuesday, 22 March 2022
Recorded by Gershon Joseph, Precision Content Authoring Solutions
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Dawn Stevens, Frank Wegmann
Business
========
1. Roll call
Regrets: Eric Sirois
2. Approve minutes from previous business meeting:
15 March 2022
https://lists.oasis-open.org/archives/dita/202203/msg00024.html (Harrison, 19 March 2022)
Dawn Stevens seconded. Approved as submitted.
3. Announcements
None
4. Action items
[updates only; see agenda for complete list]
15 February 2022:
Robert: Add objects attributes to cleanup work list
- Robert- We are removing a bunch of attributes. tab-index attribute has been deprecated in HTML 5. Other depracated attributes on element have been removed from 2.0 draft spec.
[Kris to mark this item as completed and Kris and Robert will discuss the tab-index attribute.]
15 March 2022
Kris: Add new stage two proposal to the Wiki tracking page COMPLETED
Robert: Create GitHub card for the new proposal to add an attribute to cover cascading of roles
5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
5a. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion
Remove classification domain and add new element
https://lists.oasis-open.org/archives/dita/202203/msg00022.html (Eberlein, 17 March 2022)
Kris - for proposal #647, proposal reviewed by Carsten and Gershon on TC and also reviewed by Joe
Gelb (Zoomin) and users we know who use subject scheme. Everyone but Payton sent back a response.
Kris summarized the content of the proposal.
Eliot - "key for image" should rather state "key for any non-DITA resource".
Kris - no processing requirements in spec, but we'll leave that open to maybe add to a future spec
release. Reviewers corrected points in the proposal. Gershon raised whether subjectrefs should be
applicable to keys defining images. To keep the proposal simple, we're not addressing any broader
classification in this initial round of the feature.
Eliot - I agree with Gershon's concern. I think it should be applicable to all keys, so we should
not limit to only topics. Since we're not proposing any processing requirements, I don't see why
we should limit it to topics, but appreciate the desire to keep it simple for 2.0.
Discussion on how cascading would work with subject scheme assignment that needs to change on
some child topics.
Kris - use @cascade="no-merge" and specify @subjectref on the child element. We'd want
it to apply to chapter, part, glossref.
Robert - it's specified unless there's a reason not to, so user can tag a topicref with a subject.
Kris - I'll bring the proposal back next week with an expanded list of what it should cover in
bookmap and glossaries.
ACTION: Kris to revise proposal to indicate bookmap and glossary elements that it should be
applicable to.
Kris - One of the reviewers asked about having subjecrefs availalbe on reltable. Again, we will
keep it simple now and if we want to apply it to more things in the future, we can.
Eliot and robert agreed to keep it simple.
Feedback
None
6. Review M: DITAVAL elements
Opening of review: https://lists.oasis-open.org/archives/dita/202203/msg00016.html (Eberlein, 15 March 2022)
Status of review: https://lists.oasis-open.org/archives/dita/202203/msg00030.html (Eberlein, 22 March 2022)
Kris - all comments have been handled. A larger number of comments than usual are marked as accepted,
largely because we need to wait to complete the next reivew of the architechural content on
conditional processing.
7. Comments from review of DITAVAL elements:
Discussion & decisions: https://lists.oasis-open.org/archives/dita/202203/msg00025.html (Eberlein, 20 March 2022)
https://lists.oasis-open.org/archives/dita/202203/msg00026.html (Lawson, 21 March 2022)
https://lists.oasis-open.org/archives/dita/202203/msg00027.html (Eberlein, 22 March 2022)
Request for volunteer: https://lists.oasis-open.org/archives/dita/202203/msg00029.html (Eberlein, 22 March 2022)
Overview of comments: https://lists.oasis-open.org/archives/dita/202203/msg00031.html (Eberlein, 22 March 2022)
* The term â??conditional processingâ??
Dawn brought up the point that many people equate the term â??conditional processingâ?? with just
inclusion/exclusion, not the broader category of â??filtering and flagging.â?? The spec currently uses
the term â??conditional processingâ?? frequently â?¦
Eliot - My preferred term is "applicability", in that in the source, applicability can be used to
do filtering or flagging.
Scott - I prefer "conditional processing" in the FrameMaker sense.
Robert - to me, it's always been the set of things you can do with ditaval.
Kris - "conditional processing" is what we used at IBM, though I'm familiar with applicablity
from S1000D and other SGML variants. Maybe we just need to say clearly that "conditional
processing" equals "filtering and flagging".
Robert - we currently try to be consistent and refer to "conditional processing attributes".
Frank: "efficiency control"; there is a German equivalent to "conditional processing", so I think
the latter is what most people are familiar with.
Dawn - need to emphasize the flagging aspect of it, because of FrameMaker's usage as only
include/exclude functionaltiy without any flagging ability.
Kris - the other reason I think a lot of dita users are not aware of flagging, is due to using a
CCMS (SDL) that does not support flagging.
Agreement to use "conditional processing" with an emphasis that the term means filtering and
flagging.
Nancy - we should always link back to the arch spec topic so users can easily get to the
intro/description of "conditional processing".
Kris - we're hoping to get the next review out on Thursdy or Firday, arch spec on conditional
procesing. We will ask folks not to comment again on the topics that were reviewed in the past.
The reivew won't include accurate links, due to the fact we've heavily reworked the content.
We need solid content before we redo the links.
* How we handle definitions for the â??flaggingâ?? attributes on and
Kris - conflicting comments on how to handle these in the review. Parenthetical prefix versus
text not using the parentheses. Dawn commmented to remove the last sentence, since it's clear
from the parenthetical content. Gershon suggested rewriting without the parentheses.
Nancy - i like it to be clear in the beginning
Eliot: perhaps group them in a separate section
Kris - that's hard to do, since we group the attributes in alphabetical order.
TC concensus to group the @action attributes separately into their own group.
Kris - since ditaval attributes are different from other attributes, we can take a different
approach for these.
* Request for volunteer
Eliot - I can take this. It's referring to XSL-FO, which is still on version 1.1 and has not
changed since the link we currently have.
ACTION: Eliot to check this and determine whether any changes are required to the spec.
* Overview of comments
* DITAVAL document vs. DITAVAL file
Robert - request to refer to them as ditaval files. We said no to that. Applications construct
ditaval docs on the fly, it's a doc, not a physical file. We are being more rigorous on the
rework of the arch spec, and trying to use document now consistently.
* Difference between properties and tokens
Kris - these are different terms, they are not interchangable.
Robert - we've tried to make this clearer in the updated language.
* The difference between DITA elements and DITAVAL elements when it comes to elements that
specify @href
Robert - ditaval elements are not dita elements. Ditaval is a different thing, and it won't go
through a DITA processor, therefore we don't have the same processing expectations.
@scope, @format and @type are not there, because no-one asked for it and it's not really
applicable.
* The fact that the element-reference topics are reference topics, not tutorials or a User Guide
Robert - need to provide a minimalist spec on what the element is. The job of the spec is
not to be a tutorial. User guides are left for elsewhere.
Kris - some of the topics, like prop element, are hard to read if you don't know what it does
and how ditaval works. Hoping the content in the arch spec we're currently working on
will provide a better overview of ditaval, so after reading that the prop element topic will
make more sense.
* The fact that we marked a lot of comments as â??ACCEPTEDâ??
* The difference between style conflicts between properties specified in DITAVAL documents and
what processors should do when flagging nested elements
Robert - style conflict is an edge case elemnt, when a single element in a dita topic where
the styles would conflict. It's meant for conflicts on a single element that cannot be
reconciled.
Kris - reworked the style conflict topic to move some of the content to the arch spec. This
should reduce reader confusion.
8. Examples and use cases for filtering and flagging
https://lists.oasis-open.org/archives/dita/202203/msg00032.html (Eberlein, 22 March 2022)
Kris - Please read the email and brainstorm use cases. Add your thoughts to the email list
today or tomorrow. This will help us finish off the content we're hopig to get out at the end
of this week.
-- at time, meeting adjourned --
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]