OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Meeting minutes 8 Sept 2020

Updating to fix the date of Convex from 22 August to 22 September.
Thanks Nancy!


From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Zoe Lawson <zoelawson17@hotmail.com>
Sent: Wednesday, September 30, 2020 9:58 PM
To: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Subject: [dita] Meeting minutes 8 Sept 2020
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 September.

Zoe - Thank you for Legos.

Action items
- completed data about
- updated multi-media stage 3 proposal.
- 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]