Thanks to Kris for the summary of the copy-to discussion, as I got lost in the weeds a bit. Minutes 8 Sept 2020 Attendees [I missed as I didn't know I was taking notes, this list is based on voting, so I missed any non-voting members] Zoe Lawson, Dawn Stevens, Kris Eberline, Stan Doherty, Eliot Kimber, Eric Sirois, Robert Anderson, Gershon Joseph, Scott Hudson, Frank Wegmann, Deb Bissantz, Chris Nitchie. Regrets: Keith Schengili-Roberts, Carsten Brennecke, Nancy Harrison, Carlos Evia 2. Approve minutes from previous meetings 25 Aug 2020 - Minutes by Zoë, revised. Kris - move to approve as revised. Deb - 2nd Approved as submitted and revised. 1 Sept 2020 - Minutes by Nancy Kris - Move Dawn - 2nd Approved as submitted Dawn suggests we cancel meeting in 2 weeks as that's Convex. Kris agrees. 22 Aug. Zoe - Thank you for Legos. Action items Kris - completed data about - updated multi-media stage 3 proposal. Robert - Has been puttering with style sheets stuff, just not the stuff on the list. Zoe - asked about style sheets There is a wiki page with more details Action item - Kris to touch base with Zoe about style guides, rev, and to update ReadMe Stan is documenting the style sheets for the TC Adoption Committee - should we hold off. Robert - yes, hold off for a week or two. Kris - There may be a plugin name change, but the rest should be minor/cosmetic. Stan - thank you. 5. Check in General pleasantries. Zoomin is entertaining. 6. Review of DITA 2.0 proposal deadlines Will do revised copy-to today have 2 items for stage 3. New multimedia elements for base Dawn - proposal out for review - New diagnostic element for troubleshooting Reviews should be back on Wednesday hoping to be ready for next week to discuss 7. DITA 2.0 stage three proposals #361 - Split programming and syntax domain Robert - propose Dawn - 2nd Zoe L - Yes Dawn S - Yes Kris E - Yes Stan D - Yes Eliot K - Yes Eric S - Yes Robert A - Yes Gershon J - Yes Scott H - Yes Frank V - Yes Deb B - Yes Chris N - Yes 351 - multi-media Kris - propose Scott H 2nd Zoe L - Yes Dawn S - Yes Kris E - Yes Stan D - Yes Eliot K - Yes Eric S - Yes Robert A - Yes Gershon J - Yes Scott H - Yes Frank V - Yes Deb B - Yes Chris N - Yes Kris - hope to implement these shortly. Robert, please move cards. Robert - 2 seconds. 8. DITA 2.0 stage two proposals #33 Remove copy-to [Summary by Kris] Eliot gave an overview of the reason for the proposal. In short, the @copy-to attribute was a hack and designed around how the DITA-OT works. The DITA specification should not define how processors should construct output deliverables. Yet DITA users have a need to handle multiple uses of the same topic. Discussion about whether using keys could address the issue ensued. People raised points around the differences between monolithic output (PDF) or multi-artifact deliverables (HTML). Robert Anderson mentioned the use case of wanting to have two ways to get to a topic in a TOC, but only one result for search. Eliot acknowledged that keys were not "the solution." Kris stated that she supported removing @copy-to, but had concerns about not providing a basis in the spec for replacing it. How do we provide a mechanism in the spec for processors to build "magic" around? Chris Nitchie commented that the solution required a way to formally define an externally-addressable anchor. This could be an attribute or an element. Discussion of the ways to associate identifiers with topics (keys, @id, <resourceid>, file names, etc.) ensued. Someone mentioned that a critical need was for the anchors in deliverables to be persistent across time, citing the example of a company that changed their CCMS, which changed IDs in topics and thus file names, and so all bookmarks for Web sites were broken. Kris stated that if we do not provide a syntax for identifying external anchors, we need to make it VERY CLEAR that the solution is dependent on the processor. A discussion of specializing an attribute to "restore" @copy-to ensued. Then the discussion shifted to the possibility of using <resourceid> Kris stated that if we were going to do something with <resourceid>, it needed to be in DITA 2.0. Taking away @copy-to in DITA 2.0 and then adding something in DITA 2.1 would be an anti-pattern and horrible for adoption. Gershon asked how commonly @copy-to was used, since he's only seen it with one customer. Many TC members spoke up and said that use of @copy-to was common. The fact that the TC was planning to remove @copy-to has raised fear in folks attending DITA 2.0 presentations and panel. Stan Doherty commented that the issue is closely tied to topic-level reuse; people might say (if @copy-to is removed with no replacement) "Well, we cannot do topic reuse any more." Dawn Stevens mentioned that we should not underestimate fear of keys; clients understand @copy-to but do not understand keys. Chris Nitchie suggested that we consider <resourceid> in map. Eliot stated that he would be happy to go back and consider <resource-id> in map as a possible replacement for @copy-to. Robert Anderson, chatting with Jarno Elvirta, asked whether <resource-id> would not be basically the same as @copy-to. Ran out of time, discussion to continue on the list.