| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 14 February 2017 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 20 Feb 2017 16:20:35 -0800 (PST)
[My apologies for the delay in getting these out; I got hit hard by the winter flu and laryngitis]
1. Robert will update kanban board to add items for 2.0 wrt glossary
2. Robert will move kanban item 'change name of @locktitle, and change default to 'yes' to stage 1 and add Eliot's name.
Minutes of the OASIS DITA TC
Tuesday, 14 February 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
1. Roll call
Regrets: Eric Sirois
2. Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201702/msg00026.html (Tom Magliery, 07 February 2017)
moved by Kris, seconded by Bob, approved by TC
New TC members: None
4. Action items
23 August 2016:
Kris: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN (IN PROGRESS)
Kris; I sent mail to Mekon to get DITAWeb working; hopefully that will be available maybe soon as next week.
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
25 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
07 February 2017
Everyone: Review translation of iiRDS slide deck
5. Continuing item: tcworld iiRDS slides (English translation)
https://lists.oasis-open.org/archives/dita/201612/msg00048.html (Eberlein, 07 December 2016)
[continued to next week]
6. New item from agenda backlog: glossref design
https://lists.oasis-open.org/archives/dita/201612/msg00001.html (Kimber, 01 December 2016)
https://lists.oasis-open.org/archives/dita/201612/msg00003.html (Anderson, 01 December 2016)
https://lists.oasis-open.org/archives/dita/201612/msg00004.html (Kimber, 01 December 2016)
https://lists.oasis-open.org/archives/dita/201612/msg00006.html (Hudson, 01 December 2016)
https://lists.oasis-open.org/archives/dita/201612/msg00018.html (Sirois, 02 December 2016)
Kris; this began with Eliot, to which Robert responded.
Eliot; in trying to use glossref, I got strange results, because glossref sets default for @print to 'no.' This is both surprising and unwanted; it makes the element not useful if you want to print glossary entries. I asked why this is, and got back 'we don't know'. so we should change this in 2.0
Kris; since @print is already deprecated, we'll be removing it in 2.0.
Robert; and we don't have a default for @deliverytarget. I don't think this element represents as much thought as it should have had.
Scott; one of the items where we have the same reaction as Eliot is when we're trying to use abbreviated forms, they actually don't appear in output unless glossentries appear in the printed output. even using 'resource-only' doesn't fix that. So whatever we can to to fix this would be good.
Kris; so this really covers multiple items; basic glossref design, and other issues around abbreviated-form glossentries. so part of this is just bug-fixing, but looking at glossentries and abbr.-forms would be a broader issue.
Eliot; it could be; I'd like a glossref type that provides some hooks for glossary generation.
Kris; so the real request is to correct glossref design,
Eliot; yes, define reqs around glossary map structure.
Kris; do we have any data points around who's using the stuff that came with 1.2 for glossaries?
Dawn; it's definitely been an issue, and we mention it in our trainings for clients. (to change @print to 'yes')
Bob; I've found that wrt the model in bookmap for putting in a glossary, that there are so many alternative ways to put it in that it becomes a problem - either a gloss map, point directly, etc., etc. Some of them don't work with other stuff.
Kris; and this is getting into specifics of PDF output... But not about how folks should/could use glossary
Dawn; another issue; clients will use 'term' but then that doesn't work together with glossref.
Eliot; just fyi, the client that got me into this is a large user of DITA (hundreds of manuals)
Kris; so we need a card on our 2.0 board for this. Eliot, do you have a card title?
Eliot; we want to capture gloss-related reqs a bit more formally. See how that translates to reqs.
Kris; Robert, please add these as new items to our project board. 2 items, one is glossref design wrt @print, other is 'glossary-related requirements'
Kris; BTW, Robert has updated the password for the Kanban board. We'll need to look at that today.
ActionItem: Robert will update kanban board to add items for 2.0 wrt glossary
7. New item from agenda backlog: Difficulty of interaction between related-links and reltable links
https://lists.oasis-open.org/archives/dita/201610/msg00112.html (Eberlein, 27 October 2016)
https://lists.oasis-open.org/archives/dita/201611/msg00005.html (Nitchie, 3 November 2016)
Kris; do we want to add this to 2.0? Chris mentioned that he'd be willing to work on this in 2.0. Not something that's so important to me, but is there a way we can make this easier, and are there changes we want to consider in 2.0 for linking in general?
Scott; one suggestion we give our writers is not to use related links.
Eliot; there's an issue around reltables; the spec is unclear on the implications on reltable in a map that establishes a keyscope; we need to nail that down; it could certainly have implications for how you manage sets of reltables. I can't imagine managing large sets of reltables at the map level. Also, I'd like to be able to copy link data into reltables.
Kris; most of us are used to recommending 'use reltables rather than related-links.'
Chris; it's a spatial problem too. From a given topic, it's hard to get a definitive list of all the related-links that will appear; have to go up and look at every map and topic.
Kris; we haven't talked about changes to early design of reltables and related-links.
Robert; just as historical context, reltables came out of a design by Michael. as a way to track links. related-links was a way to specify them within a topic 'if you must.'
Mark; is the answer as easy as changing topic to contain reltables instead of related-links?
Chris; actually, it's the opposite; the goal is to remove linking from within topics completely and put it only in maps.
Eliot; if we define a specialization of topicref whose tagname is 'link', (ignoring other attributes...)
Chris; what reltables give you is bi-directionality; I can't think of another way to achieve that. But that sometimes needs to be turned off... For casual authors who just want to author related-links within a map.
Eliot; I think a link only within a 'reltables zone' in a topic, would be a problem. reltables are fundamentally diff from the hierarchy of topicrefs that a map defines. And when I'm describing topicrefs, I often have to say 'except for topicrefs within reltables'.
Tom; I've always considered it a bonus that in Xmetal you can create a reltable by simply copying links from somewhere else. If we make the change to 'link', any tool would have that capacity.
Eliot; I don't know if that would have to happen, if it was an expansion of table entries content.
Kris; There's also an issue of managing the slew of reltables and figuring out where links go to after processing.
Don; in early IBM days, some teams created books solely based on topics. Analyze related-links. created contents without a map, then analyzed related-links to see what structure they should be a part of.
Kris; was this prior to the existence of maps?
Don; no, they already existed; the author needed to be an earlier adopter of the technology; she abandoned it pretty quickly. It might be worth talking to her.
Robert; I don't remember that.
Kris; so any consensus on this agenda item?
Kris; if I come up with any ideas between now and next week, will bring them back.
8. Continuing item: Formal work on DITA 2.0
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
Report back from small group (Kris, Robert, Tom, Maria)
Review of cards on project page
Backlog of random items
Stage one (in progress)
Kris; small group had a presentation
Maria; I found it really helpful; hope it will also be for new members of the TC
Robert; it was a good refresher for me; noted that what I remember didn't match what we'd written down.
Kris; I think it was a productive call; will be one of first items on next week's agenda.
[review of kanban board]
1. redesign hazard statement domain
Eliot; Jang has complained about this, he has some definite ideas about it.
Robert; I've heard Jang talk about it. but he's not a voting member. Can't have someone lead a proposal if they're not a voting member.
Chris; any members who represent machinery industry?
Keith; I'll reach out to Jang and talk about it.
AI; keith will do this
Kris; for 1.2, hazard statement domain was championed by Chris Kravogel. ended up with an issue between him and the spec editors wrt what the DITA spec said vs. what the ANSI spec says. There was also a difference between what the spec said and how the DITA-OT rendered things.
Eliot; one thing is that the hazard symbol appears after the statement rather than before.
Kris; but that is a tooling/rendering issue, rather than a standards issue.
Robert; I would think they'd want the spec to actually mandate specific images according to ANSI spec. We couldn't do that.
2. change name of @locktitle, and change default to 'yes'
Robert; I have trouble with that myself, but I don't know that we should make those changes
Eliot; I'd be all for making that change
Tom; it took us a lot of work to make this work.
Kris; but what would be the impact of making these changes, in terms fo existing content
Robert; if we keep it the same, but change the default to 'yes' would wreak havoc.
Eliot; we need new @s and we need to deprecate the old ones.
Robert; Eliot, would you be willing to come up with a design for this?
Eliot; I might be willing.
Robert; I might be willing to just do away with it, have never found it useful.
ActionItem; Robert will move to stage 1 and add Eliot's name.
3. improve quality for tech content architectural topics.
Kris; I think this is part of a larger topic of splitting the base from tech content pieces of spec. We want to make sure we move improved tech content arch topics into the split base/tech content. Let's move this into stage 2 item owned by Bob
4. bring consistency to URI/keyref format for referencing map elements and topic elements.
Kris; do we know who brought this up?
[to be continued]
12 noon ET close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]