dita — archive

[Nancy Harrison]

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 Document Name : DITA TC Meeting Minutes 22 March 2022 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 : 2022-03-29 11:22:03