dita — archive

[Nancy Harrison]

Submitter's message ActionItems: 1. Kris will look at existing content, see what we say, and bring it back with her suggestion for what to say, including a suggestion for location of normative language around marprefs and rel tables. 2. Kris will do initial rework on section 9.3.2.4 (topicgroup) and bring back to TC. 3. Zoe will forward a proposal on respecializing imagemap to TC. ================================================= Minutes of the OASIS DITA TC Tuesday, 2 July 2019 Recorded by Hancy Harrison link to agenda for this meeting: https://wiki.OASIS-open.org/dita/PreviousAgendas Attendance: Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Hancy Harrison, Eliot Kimber, Zoe Lawson, Tom Magliery, Keith Schengili-Roberts, Dawn Stevens Business ======== 1. Roll call Regrets: Alan Houser, Carlos Evia, Carsten Brennecke, Chris Nitchie 2. Approve minutes from previous business meeting: 18 June 2019 https://lists.oasis-open.org/archives/dita/201906/msg00068.html (Bissantz, 19 June 2019) Moved by Kris, 2nd by Nancy, approved by TC 3. Announcements: New TC members: Jaquie Samuels and Graydon Saunders from Precision Content 4. Action items 11 September 2018 Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC: due 09 April Overdue 13 November 2018 Eliot: Test refactoring of grammar files; due end of June 18 December 2018 Eliot: Investigate issue re LearningAggregationsTopicrefConstraintMod.xsd; due end of June 05 March 2019: Alan: Update DITA 2.0 files for appropriate elements with LwD hint values for @format and create a pull request; due 23 April 09 April 2019 Eliot: Does SVG zip file need to be in techcomm grammar folder? - due date changed to Aug 15 Kris and Tom: Finish up any discussion about examples in ArchSpec files - Kris and Tom will confer to see if this is still open. Nancy: Review LwDITA e-mail threads; create a Wiki page to track items, so that we can ensure that all items have been discussed and resolved - Nancy will post the location of the page to the TC list, and Kris will add a link to the front page wiki. 30 April 2019 Kris: Request OASIS Open repository for tools/scripts to aid users in moving to DITA 2.0 - Kris; we need maintainers, etc., for this. 07 May 2019 Robert: Respond to Chris P on dita-comment (COMPLETED) 28 May 2019 Kris and Robert: Revise content and run it by Eliot (Draft-comment in spec WD03, section 3.3.3, page 37) - everyone in TC should be looking at these. Robert: Take an initial look at fixing this (Draft-comment in spec WD03, section 3.4.4, page 52) Chris: Look at draft-comment in spec WD03, section 8.2.2.19, page 210 18 June 2019 Kris: Send Deb attendance for the meeting (COMPLETED) Kris: Cancel meeting for 25 June 2019 (COMPLETED) Kris: Send out multimedia domain PDF (COMPLETED) Kris: Resubmit stage two proposal for indexing changes and change indexterm-base to index-base (COMPLETED) Robert: Answer Chris P's latest comment on dita-users (COMPLETED) Robert: Set up submodule for DITA for TechComm repository Robert: Work on remaining stylesheet issues; see https://wiki.oasis-open.org/dita/stylesheetBacklog 5. DITAweb review of multimedia domain topics https://lists.oasis-open.org/archives/dita/201906/msg00067.html (Eberlein, 19 June 2019) DITAweb status? - Kris; Alan has been pushing Congility to update their DITAWeb server to a more recent version, then we'll start review. 6. Draft comments in latest working draft from TC attention We will review and discuss them, starting with page 258 Working draft 04: https://lists.oasis-open.org/archives/dita/201906/msg00000.html a. - this is the comment on p 258, section 9.3.2.3, wrt processing expectations for mapref; do we need normative statements? - Kris; this is the only place in the spec where we talk about what x should do wrt rel. tables in a child map. - Eliot; we do need mormative statements; we have edge cases, e.g. branch filtering on reltables. If you have a reltable inside a filtered branch. you need to account for that in any statements we do make. - Kris; does anyone think we shouldn't make normative statements about hierarchies and how reltables work? [no response, so TC agrees that normative statement is needed.] - Eliot; I'd expect this to be covered somewhere in arch spec around maps. - Kris; I added this comment precisely because I don't think it is covered there. - Robert; I don't think it covers it either, and it needs content; so we need a normative statement. But it shouldn't be in this topic; it's a much more general issue. - Eliot; I agree - Kris; the point of reviewing it is to see what needs to be said, and where. - Tom; is there a different place in the PDF where we should look right now? - Robert; I don't think we cover this in the abstract sense - Kris; you could check TOC, and we could discuss where we know it's not; e.g. in the overview of DITA w/ditamaps, all that is non-normative. - Kris; I don't think we have anything about what maps do with mapref & reltables. - Tom; is there a place where this content should fit? - Kris; not in DITA markup, maybe in map processing section. - Tom; Section 3 Overview of DITA is mostly non-normative, maybe a description should be there, and any normataive stuff in 4. - Eliot; in the 1.3 spec, there's an example in section 2.2.2 (DITA maps), but that's obviously not normative. - Kris; DITA map examples are now 3.4.5, all non-normative. - Eliot; so the behavior in this example needs to be described in a normative section. - Kris; can anyone else look at this as well? - Deb; I can - Kris; this is exactly what we're trying to do; get a handle on where we have useful info, but in the wrong place, that should be somewhere else. We may also have it in reltable topic; we NEED it in arch topice. ***ActionItem: Kris will look at existing content, see what we say, and bring it back with her suggestion for what to say, including a suggestion for location of normative language around marprefs and rel tables. b. next comment is p. 259, section 9.3.2.4, 'topicgroup' - Eliot; I'd like this statement to be a ilttle more definitive, titles in topicgroups are never intended for presentation, and shouldn't be treated the way they're treated in topicheads. - Kris; so does saying it has no defined purpose convey that? - Tom; we could add 'and should not be used for presentation.' - Eliot; also, we're extending the title-alt mechanism, so this shouldn't be the only choice... - Kris; what stage is that proposal? stage 3?? - Eliot; I think so... this is a weird situation; it didn't originally allow the title element; now that it does, we need to explain its limitations. - Kris; we're also making normative statements about processing expectations. - Eliot; those might cover it... I think that something labeled 'processing expectations' should never be normative, anything normative should be a 'processing requirement.' - Kris; we've had this discussion before; the outcome was that anything having to do with formatting would go in a appendix. - Eliot; so i'd recommend that this statement should be in the appendix; it's really a rendering issue, not a processing issue - Kris; so should we change the title for this section to 'rendering expectations'? - Eliot; yes - Tom; but that still has same issue; your report of titles would still not be able to be rendered... I don't think there should be a normative statement on this at all; it depends on what you're doing with the navtitle. Really, it would be more usage information, rather than expectations. - Eliot; yeah, another thing is that the semantic of topicgroup is that it doesn't contribute to navigation hierachy in map, so not used in normal rendering. - Kris; it relates to overarching statements about map processing; this is only place in spec where we talk about topicgroup. - Tom; and any overarching discussion should be in arch spec. - Kris; so, we have a normative statement, because it was in 1.2 and 1.3; when we introduced navtitle, there was no way to keep it out of topicgroup. - Tom; this description should give that sense of topicgroup, that it groups topics without affecting hierarchy. - Eliot; that statement is in 1.3 element ref for topicgroup, in section 3.3.2.4. - Kris; so we need to bring it back into the shordesc of this topic as well. If we need to make a normative statement, it should be in 'rendering expectations', and it should be qualified, e.g.'for publication of document with a hierarchy this will be ignored by processor' We'll need to flag this topic for extra review. - Eliot; loking thru 1.3 spec, in 2.4 navigation, there's an entry describing this expectation for topicgroups. - Kris; that item might be also a good candidate for moving into a group of topics about maps and map hierarchy. ***ActionItem: Kris will do initial rework on this topic and bring back to TC. c. section 9.3.2.5 'topichead'] - Kris; Eliot, your thoughts on this? - Eliot; topicgroup is unique, it's the only form of topicref with behavior at odds with other topicref elements, otoh, topichead has similar behavior to topicref. - Tom; but it took me a really long time to figure out the difference between topichead and topicgroup; kind of sounded like the same thing. - Kris; I haven't seen that specific confusion, though I've seen that people couldn't understand what topicgroup could be used for. - Eliot; the only other place with special behavior for topichead was chunking in 1.2; there was a special combination of topichead and chunking, but that was to work around DITA-OT issues. - Tom; it seems like this, as well as topicgroup, needs mention in a higher level discussion about map rendering, the items should go together, and the shortdescs for these 2 elements should be evaluated together. - Kris; I'm happy to try to do that. it also underscores that it's a good idea, when we have architectural content about maps, map processing, teltables, etc, that we review architecture content with element ref content for those elements. - Kris; wrt this comment, does it need a normative statement? - Eliot; not really, because it acts just like a topicref that way, so I don't think it needs one. - Kris; we can say we don't want to make a normative statement here, but we need to review this topic. Robert and I are trying to be very careful about not using should, must, may in any non-normative context. So that will trigger some of our discussions. 7. DITA 2.0 stage two proposals Vote a. #253: Indexing changes https://lists.oasis-open.org/archives/dita/201906/msg00053.html (Eberlein, 14 June 2019) - Kris; moved to bring #253 to stage 3, Robert 2nd Voting Results: yes votes: 11 (Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Hancy Harrison, Eliot Kimber, Zoe Lawson, Tom Magliery, Keith Schengili-Roberts, Dawn Stevens) no votes: 0 - For stage 3, Dawn, Bill, and Eliot will review. b. #217: Removing domains attribute / reworking attribute specializations https://lists.oasis-open.org/archives/dita/201906/msg00057.html (Anderson, 14 June 2019) - Robert moved to bring it to stage 3, Bill 2nd Voting Results: yes votes: 11 (Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Hancy Harrison, Eliot Kimber, Zoe Lawson, Tom Magliery, Keith Schengili-Roberts, Dawn Stevens) no votes: 0 - for stage 3, Eliot and Tom will review. 8. DITA 2.0 stage one proposals Allow in same locations as https://lists.oasis-open.org/archives/dita/201906/msg00026.html (Hudson, 10 June 2019) https://lists.oasis-open.org/archives/dita/201906/msg00027.html (Kimber, 10 June 2019) https://lists.oasis-open.org/archives/dita/201906/msg00028.html (Eberlein, 10 June 2019) Additional e-mails ... - [On hold until Scott Hudson returns from vacation] 9. Review of DITA 2.0 proposal deadlines https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 - Keith; proposal #107, move deadline to end of July - proposal #29; Keith will ping Eric on this - Eliot; proposal #33, move deadline to mid-August for all deadlines Other: - Zoe; what about my question about putting an imagemap in a figure? - Kris; I think it would be a good idea to re specialize it from something like 'div' instead of 'fig' so that it can be nested. - Eliot; I like the idea - Zoe; I'm willing to create a proposal, but not sure I know enough to actually implement it all by myself. - Eliot; if it's just changing the specialization base from fig to div, should be pretty straightforwad. - Kris; Zoe, if you want, put forth a proposal; though to me, div seems a bit strange, just like fig. - Eliot; but div is just a generic container, and it would get around Zoe's problem. ***ActionItem: Zoe will forward a proposal on this to TC. 11:37 noon ET close -- Ms. Nancy Harrison Document Name : DITA TC Meeting Minutes 2 July 2019 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 : 2019-07-03 03:13:43