Groups - DITA TC Meeting Minutes 10 December 2019 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItems:  
1. Robert will create project card for fixing change-historylist.
2. Robert will fix change-historylist grammar files in github branch for hot fixes.
3. Robert will handle updates regarding @encoding and nested fallback element for coderef, svgref, and mathmlref elements.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 10 December 2019
Recorded by Hancy Harrison
link to agenda for this meeting:	
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Dawn Stevens, Eric Sirois, Joyce Lam, Frank Wegmann, Keith Schengili-Roberts   


Business
========

1. Roll call
        Regrets:  Deb Bissantz


    Approve minutes from previous business meeting:
        03 December 2019
            https://www.oasis-open.org/apps/org/workgroup/dita/download.php/66383/minutes20191203.txt (Harrison, 10 December 2019) 
moved by Kris, 2nd by Dawn, approved by TC


3.    Announcements:
        Reminder: no TC calls on 12/24 or 12/31


4.    Action items
[updates only; see agenda for complete list] 
        28 May 2019: 
            Chris: Look at draft-comment in spec WD03, section 8.2.2.19, page 210 IN PROGRESS 
- Chris; this is done
        19 November 2019
            Robert: Create new branch and make fix for XSD issue (COMPLETED)


5. New item: Minor defect in change-historylist grammar files
        https://lists.oasis-open.org/archives/dita/201912/msg00018.html (Anderson, 05 December 2019) 
- Robert; found this last week, I noticed defect in release mgmt domain; change-historylist is specialized from metadata, but mistakenly has @s matching its children, which are specialized from 'data.' It should/will be fixed in 2.0.  The question is; should we add it to list of known issues for 1.3 (with similar trivial defects)?
Kris; any objections to fixing this in 1.3 in our branch for hot fixes?
[none]
***ActionItem: Robert will fix change-historylist grammar files in github branch for hot fixes.
- Kris; any objections to treating this as a bug for 2.0?
[none]
***ActionItem: Robert will create project card for fixing change-historylist.
- Robert; we don't even really need a project card, but I'll make one


6. New item: Question about include element and existing specializations
        https://lists.oasis-open.org/archives/dita/201912/msg00012.html (Anderson, 03 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00013.html (Nitchie, 04 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00014.html (Anderson, 04 December 2019)
- Robert; we seem to have left the fallback element out of the coderef, svgref, and mathmlref elements, as well as the @encoding attribute, even though both are preent in the new include element from which they have been rebased. Was this an oversight, or deliberate? 
- Kris; when we did this we hadn't started working on 2.0 techcontent grammar files, so it's probably an oversight.
- Robert; these are 3 elements in techcomm that were based off new include element; I've begun updating them, but not finished because of these questions.  
- Chris; this was my proposal, issue was part oversight, part 'can't see the forest for the trees'; I'm fine with all of Robt's suggestions.
- Kris; any objections?
[none]
***ActionItem: Robert will handle these updates regarding @encoding  and nested fallback element.


7.    DITA 2.0 stage three proposals
        Vote
            #29 Bookmap update
                https://lists.oasis-open.org/archives/dita/201912/msg00001.html (Eberlein, 01 December 2019)

[moved by Kris, 2nd Eliot]
Voting results:
yes votes:		15 (Robert Anderson, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Dawn Stevens, Eric Sirois)
no votes:		 0
[motion approved]

        Initial discussion
            #217: Remove most uses of domains attribute
                https://lists.oasis-open.org/archives/dita/201912/msg00028.html (Anderson, 09 December 2019) 
- Robert; given earlier discussion to get rid of @domains, usage of which has gotten more complicated every release.  It's one of the most complex parts of grammar, and one of the least practical @s. This proposal lets us remove lots of complicated normative rules.  I got good feedback from Carsten and Eliot. Do we also need to remove the element called domainsContribution [just in RNG]?
- Eliot; that element is only part of the code to generate DTD from RNG, not in grammar files proper; it's not part of our externally-defined RNG files.  If there's no @domains, then it's not necessary.
Robert; agree, so we can replace domainsContribution with specializationsContribution in RNG files for generating DTDs.
- Kris; comments or questions?  This is really about 1) removing @domains, which was both horrifically overloaded, and never met planned use case, and 2) adding a new attribute, @specializations, with new simplified syntax for specializing @s.
- Robert; leaving open that more features could possibly be added in future, but that's not really likely; I personally would have to hear a huge case made for it...
- Kris; before we update this, please update the propodal to list you as champion; right now just has original boilerplate.
- Robert; will do, and will replace Eliot's notes with actual change.
- Kris; any objections or concerns?
[none, vote next week]


8. New item: Variable key text and link titles
        https://lists.oasis-open.org/archives/dita/201912/msg00015.html (Nitchie, 04 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00017.html (Anderson, 04 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00024.html (Eberlein, 09 December 2019) 
- Chris; in discussion last week, agreed we needed a new element for variable text for key ref, as opposed to keyword, etc. came up with example in above mail, for now calling it keytext. a xref to that key would make sense to prefer link text, whereas for keyword xref, perfer keytext. so should linking elements use liktext and other refs use keyref/ or do we need separate keytext element? can we use linktext for all? gen'l feedback was, yes we should have both, and of options, using variable text option as first choice would be preferred, then linktext, then fallback to normal processe
- Kris; feedback was from both Robert and me.  i suggested it would be pref to name element something like variabletext, which is term most used in tech writing for this usage, or might want a more user-centered name
- Chris; slightly more on keytext side of argument. from a map author's POV, this element has no meaning outside of key mechanism, and all those terms start with 'key' in name. if we had other uses for variabletext, not strictly bound to ekey mechanism, then it would make sense. I'm not a writer, but a map author
- Eliot; i'll point out that i defined a mechanism in dita4p which does use the term 'variable' for that reason i'd tend to reject the term 'variabletext' here
- Zoe; i already have an element named 'varname' in sfw, so if you give me a elelement variabletext, my brain goes over there
- Kris; where should this be available? obviously in maps
Chris; a sibling to alttitles under topicmeta
- Kris; take back my sugeestion of variabletext, more for mmmIA / map authors., not for writers.  
Robert; one more edge case coment.  Chris  comment about this having no meaning besides defining a key. I'm not sure of that. Not sure that adding @keys mechanism
- Chris; that being the case, i come back to'why not just use linktitle?
- Robert; because in so many cases, it's not just a link and it's not a title.  it wouldn't have to be a fallback
- Chris; think you're proposing a level of scope creep.  if there's no keytext, goes back to linktitle.
- Robert; if that's explicit, then I'm ok
- Chris; do you want the fallback to work both ways? sounds like that's what you're proposing
- Robert; it was; kind of messy. thru history of implementing this, we've defined a fallback and left something out, so these elements are there and people get annoyed if they're not used; not sure which is the most appropriate direction for fallback.
- Eliot; I understand exactly it as exactly one, a more appropriate name would be keytext, whereas linktitle implies it's only for something that's a link. but it's pretty fuzzy..
- Robert; do we need linktitle at that point? if fallback goes to one or other, do we still need linktitle?
- Kris; are we still in #8, or have we gone on to #9
- Chris; they're deeply intertwined...  but still on #8
- Eliot; it's up to processor to decide, if there are multiple options
- Chris; do we still need linktitle? Because titlealts are available in topics as well as maps, and linktitle isn't available in topics. in a topic context, linktitle is a new thing. if we don't need it, we don't add it to topics.
- Eliot; makes sense to me to have linktitle as oppsoed to navtitle, though rare to need the usage.
- Kris; can you give an example, Chris?
- Chris; whatever use case you have for linktext, minus keydef; e.g. parent/child, or reltable definition.  If you don't explicitly set ilnktext on link, would pull it from linktitle; what's new is ability to author 'linktext' in titlealts at map level.
- Eliot; potential harm is that we have to explain it.
- Chris; it's different from navtitle; they have relationships among themselves
- Eliot; I have a lot of experience of pruning things away beacause no one uses themn.
- Zoe; getting lost trying to follow what title goes where; I'd like to see a diagram... there's too much history.
- Kris; also a lot of 'heres' what we/orig. designers were thinking 20 years ago.
- Robert; once we get markup settled, I'd want examples of topicrefs using keyrefs for every possible condition, to think thru how they resolve and how I'd want them to resolve.
- Kris; let's go to #9, has to do with scraping our current reules for resolving variable text


9. New item: Scrapping current rules for resolving variable text
        Note that these e-mails had an incorrect subject line, "Re: [dita] Question about include element and existing specializations"
        https://lists.oasis-open.org/archives/dita/201912/msg00019.html (Nitchie, 05 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00020.html (Anderson, 05 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00023.html (Gershon Joseph, 09 December 2019)
            https://lists.oasis-open.org/archives/dita/201912/msg00025.html (Eberlein, 09 December 2019)
- Chris; I wound up at discussion ofh ow ilink text is related to variable text for keyrefs. frules from 1.2 not well-defined, attempt to do in 1.3, but it's messy, and by intro'ing a new keytext element, we've have to fit it into those rules, or taek them out and replace them with new ones. So are we comffortable with vastly simplifying those rules. Cost is that there are many instances of these rules that would be practically implossible to automatically migrate. almost any part of key tag could end up being used, same keydef could providedifferetnt text in diff cases. manycases will require manual cleanup.
- Kris; Robert mentioned there's a fair amount of variety in patterns for usage
- Robert; from different processing, and history; it's very hard to work with. in favor of simplifying rules and getting rules that are hard to work with. keys that resolve diferently based on which element is ref'ing them.
- Eliot; I agree.
- Robert; there were strong proponents for that use case, but I've never seen it used once.
- Kris; there's been a level of comfort from user comm. for using keyword. that's the pattern i've seen most frequently. what contains keyword can vary a lot.  do they have the metadata element.
- Chris; one strong argument agaisnt using keytext is existence of keyword. but most common pattern i've seen is -spec says usinge linktext - example using keys to define keyref, uses kyword inside topicmeta
- Kris; until not that long ago, dita-ot didn't support usig linktext within keydefs. during a period of time, when users wanted it t owork, they had to use keyword.
- Scott; we're deeply in keyword hell, would really like a fix. 
- Kris; close to top of hour, haven't gotten to the actual proposal; want TC to read proposals and comments; will raise point; as it read it, i can understand fact that t dealing with titlealt and kyref in one proposal, because they're related, but it does make me nervous, wonder if we do need to separate proposals into one for keytext and one for atlttiles.
- Chris; it can be an awkward fit; i went back and added key stuff to it
- Kris; wonder if we need a separte prposal for keytext, that gives all examples, and focuses on migration issues if we do this
- Robert; it's a big enough hange tos tand on its own, but putpose of proposal isnot to wrtei down everything on paper
- Nancy; but not everyone does understand all the examples
- Robert; 
[to be continued]

10. DITA 2.0 stage two proposals
        Vote
            None 
        Initial discussion
            None 
        Early feedback
            #16 titlealts improvements
                https://lists.oasis-open.org/archives/dita/201912/msg00022.html (Nitchie, 06 December 2019) 
volunteers for review?  Kris, Eliot
- Chris; assuming discussiion passes, i've got most of changes made.



12 noon ET close
        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 10 December 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-12-16 12:30:30