dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 15 December 2020 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Sun, 20 Dec 2020 00:22:18 +0000 (UTC)
Submitter's message
ActionItems: None
=================================================
Minutes of the OASIS DITA TC
Tuesday, 1 December 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Deb Bissantz, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann
Business
========
1. Roll call
Regrets: Carsten Brennecke, Carlos Evia
2. Approve minutes from previous business meeting:
08 December 2020
https://lists.oasis-open.org/archives/dita/202012/msg00021.html (Wegmann, 13 December 2020)
17 November 2020
moved by Kris, 2nd Dawn, approved by TC
3. Announcements
none
4. Action items
[updates only, see agenda for complete list]
Action items
08 December 2020
Kris: Respond to Chris Trenkamp on dita-comment COMPLETED
Robert: Add removing mapkeyref attribute to cleanup issue
- Robert; this is done.
5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business discussed]
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
[updates only; see above link for complate list]
Stage two
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
? 2020: Initial TC discussion
? 2020: TC vote
- Eliot; the revised version went out on 13th; received response by Deb
- Nancy; I'll get my response to you today or tomorrow
Stage three
(Nitchie) Add title alts to map (https://github.com/oasis-tcs/dita/issues/16)
? 2020: Initial TC discussion
? 2020: TC vote
[see agenda item #9 for related discussion]
(Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
?: TC vote
[see agenda item #8 for vote]
7. DITA 2.0 stage two proposals
[no updates]
8. DITA 2.0 stage three proposals
Vote
#345 New element for defining variable text
https://lists.oasis-open.org/archives/dita/202012/msg00015.html (Eberlein, 08 December 2020)
moved by Kris, 2nd by zoe
Voting results:
yes votes 13 (Robert Anderson, Deb Bissantz, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann)
no votes 0
9. Applicability of linktitle
https://lists.oasis-open.org/archives/dita/202012/msg00020.html (Nitchie, 13 December 2020)
https://lists.oasis-open.org/archives/dita/202012/msg00022.html (Joseph, 14 December 2020)
https://lists.oasis-open.org/archives/dita/202012/msg00023.html (Anderson, 14 December 2020)
- Chris; as per my email above, I was surprised that the way my proposal replaces linktext with linktitle creates significant backwards incompatibility with 1.x releases; I assumed linktext would be the text for all links. But replacing linktext in maps with new linktitle, for all links that don't specify linktext won't be bacwards compatible. It might be advisable to revise what I've written so linktitle is analogous to linktext and only applies to things for map structures, but I think that's not really a good idea. If we make this change and don't fix it. we'll have one way for generated links and another title for other links, and that would be confusing. I'm not sure what to do now; we have to pick one, but there's not a clean way to be backwards compatible and also do a clean job. I don't think users would be surprised by the change, but it soulnds like that might not be the case.
- Robert; I would be surprised by the change, but I'm not your average writer. I have no idea how common it would be. I do think that most people probably never run into this. But also, I don't remember a discussion of why these titles cascade into the document. If everyone uses keys, the issue just goes away. I think with using keys as a best practice, it may not be an issue.
- Eliot; I'm not sure I understand 1.3 practice; do we mean using specifically the link element, or any link?
- Chris; just the link element.
- Robert; elements that include either @xref and @href.
- Eliot; so if I have a link to a topic that's not a keyref, how do we know what linktext is in that context?
- Robert; if you assume 5 references to the example.dita in Chris's proposal - none of them use keys, and one of them uses custom linktext. Currently, when a processor generates a link based on the one that uses custom linktext, it uses the custom linktext. If you have a bunch of other references, it will query and get the title. Chris's proposal flips that. if one of them specifies a linktitle, all the links to it will use that linktitle.
- Eliot; so if topicref with linktitle has children with links, they'll use that text as well?
- Kris; I was reviewing the proposal when I saw the comment, and I was surprised, because I'm very familiar with 1.3 Open Toolkit method. I think if we have a change here, the output will surprise a lot of people.
- Chris; it may just be what we're used to, whether it's the OT vs. other procesors. When you have a URI link, in a map, you have to pick an instance in that map structure where you'll land. It involves looking in the map to find the context.
- Eliot; if the reference is a URI reference?
- Chris; then you can pick one...
- Eliot; I would say that behavior is unjustified. At best, if there's only one usage, you can pick that one.
- Chris; but implementations have to resolve that issue; even if it's a choice to make it a dead link is a choice.
- Eliot; but the spec doesn't give you any help in making that choice. If you use a direct link, there isn't enough info to determine what the actual usage is; you can make choices, but that's local to your processor/implementation. The spec can't say anything about it. The only choice you have is to use keys, so the problem you've identified isn't one we need to solve, because it isn't a solvable problem. You described a behavior different from OT, but it's not wrong, and the spec can't have any opinion on it. To the degree that the DITA spec can define things, it would be 'the inference you make must be this one...' I don't think there's actually a problem. If you use keys, there's no problem; if not, you get what you get...
- Robert; I think the proposal as written now, it adds rules for how it would be treated, and I think that's a problem.
- Eliot; in case of 2.0, if you have a link to a direct URI reference, how can a map tell you anything?
- Chris; my proposal implies that it can.
- Robert; the proposal implies a known root map.
- Eliot; but there's no info in that direct URI reference that can tell me what use of the target topic I intend my link to reflect; it could have been called by my map, or a different map; none, once, or multiple times. You could define a business rule to solve the problem, but it's not determined by the spec.
- Chris; the existence of a root map is insuffiicient to answer questions that need to be answered in the proposal. My opinions wrt DITA is that, if you're publishing a map, any resolution implies finding the target of the link; whatever method you use, you have to pick one.
- Eliot; but there's no guarantee that there's any map that points to the target.
- Chris; once you figure out what the target is, then you have to determine the title of the link, and for that you look at the map. If it's not ok to make that assumption, then I can take it out and add a statement about what the processor has to do.
- Eliot; the processing you describe in case of direct URI reference could be 'in this case, it's up to the processor to determine which is the correct target. In a map, the map context determines use context."
- Chris; what about a direct URI in a reltable?
- Eliot; you shouldn't have them in reltables.
- Kris; but the spec allows both keys and direct URIs in reltables.
- Eliot; but we need to let users know that there's no way to determine the context in that case.
- Chris; and if you're not using keys, at a certain point in processing, you still have a context.
- Eliot; yes, but we can't say what the behavior will be.
- Chris; so there are 2 issues;
1. which use context should I pick? And the spec can't determine that,
2. once the use context is chosen - however it's chosen - you should use the linktitle from the link.
- Eliot; I don't see how that could conflict with 1.3, because it was just as arbitrary there.
- Chris; 1.3 says what the linktitle is for, and it's not for empty links
- Robert; it was meant to be context-specific
- Deb; right now, that's what I expect; the default is to use the topic title, and if I put in linktext, that's an exception to the rule.
- Eliot; if that's the case, we need to stick with the 1.3 behavior.
- Chris; the assumption I made is that all processors work like mine.
- Eliot; Robert, does the spec currently disallow the behavior Chris has defined? Or does it say linktext is only for generated text?
- Robert; I don't think it says anywhere how you have to determine the link text for xref.
- Eliot; before keys, it was understood; if you had a direct URI reference, all you knew was the topic. I wonder if we have to explicitly disallow the behavior he described...
- Chris; whatever goes into the spec has to be adjusted so it doesn't assume things that can't be assumed.
- Eliot; if we stay with 1.3 behavior.
- Robert; part of the difficulty is that these are all considered titles, and these are all combined with all the topic titles, and so linktitle has cascaded into topic and can be picked up. Most titles are context-specific.
- Kris; this ties back to the fact that there's a lot of processing around maps that we've never clearly covered in the spec; we don't cover our expectations around processing maps. There's a placeholder in 2.0 for doing that, and this is part of that larger [hole/whole]. There's a lot of unspecified behavior, and the fact that keys weren't part of original DITA is a big part of that.
- Chris; so I will change title @role for linktitle, and maybe more. The current proopsal introduces s titlealt with title @role of link; that suggests just links; if it's limited to links that point to a specific use context, then I want to change the token to 'maplink', to unambiguously make it clear that this is what it is.
- Robert; that's a smart move. now that I understand your use case better, I would expect the proposal would have disallowed your process.
- Chris; the existing default is 'one input topic creates one output topic'. It should be 'one topicref creates one output topic'. Otherwise the 'prev' and 'next buttons will no longer work.
- Eliot; OT used a runtime flag to show your behavior.
- Robert; I agree with you, but OT has always held lcosely t backwards compatibility, like the spec.
- Eliot; I preented a paper on how to do this, where you have one output but multiple contexts.
- Kris; so where should we go from here?
- Robert; it sounds like Chris has some direction to take on updates to the proposal.
- Chris; Right. I'll figure something out; renaming and rewording.
[to be continued at next call]
Other:
Kris; we are cancelling next weeks meeting; will pick up Chris's proposal on Jan 5th.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]