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: Groups - DITA TC Meeting Minutes 1 October 2019 uploaded


Submitter's message
ActionItems: - no new actions items this week, but please note updated deadlines for 2.0 proposals in body of minutes; some are now due next week.


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

[meeting cancelled]

Attendance:
Robert Anderson, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Joyce Lam, Zoe Lawson, Chris Nitchie, Dawn Stevens, Eric Sirois, Jacquie Samuels, Joe Storbeck, Jim Tivy


Business
========

1. Roll call
Regrets: Deb Bissantz, Keith Schengili-Roberts


2. Approve minutes from previous business meeting:
17 September 2019
https://lists.oasis-open.org/archives/dita/201909/msg00074.html (Harrison, 19 September 2019)
moved by Kris, 2nd by Eliot, approved by TC


3. Announcements:
None


4. Action items
[no updates; see agenda for list]
- added to list; Bill B. needs reviewers for his lockmeta proposal; Eliot and Scott volunteered.


5. DITA 2.0 stage two proposals
Vote
Issue #164: Redesign hazardstatement
https://lists.oasis-open.org/archives/dita/201909/msg00012.html (Anderson, 04 September 2019)
- moved by Kris, 2nd by Eliot
Voting results:
yes votes: 11 (Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Joyce Lam, Zoe Lawson, Chris Nitchie)
no votes: 0

Continuing discussion
None
Initial discussion
None
Early feedback
None


6. DITA 2.0 stage three proposals
Vote
None
Initial discussion
None
Early feedback
None
- Kris; Eliot, we need an updated proposal from you on topicsetref so that we can vote on it.
- [side discussion on Eliot's copy-to proposal; he thought he needed more review feedback, but that is apparently not the case before we can discuss it.]
- Eliot; I'll try to get that done today, so we can discuss it next week.


7. New item: Questions and concerns about issue #29 bookmap updates
https://lists.oasis-open.org/archives/dita/201909/msg00067.html (Eberlein, 18 September 2019)
https://lists.oasis-open.org/archives/dita/201909/msg00070.html (Sirois, 19 September 2019)
https://lists.oasis-open.org/archives/dita/201909/msg00071.html (Eberlein, 19 September 2019)
https://lists.oasis-open.org/archives/dita/201909/msg00072.html (Sirois, 19 September 2019)
- Kris; I took this over from Eric, since he had too much other work to do. I posted to list some concerns, in particular, whether mapresources was to be added to mapdomain, or put in new domain, or something else. [Eric's response was that it was to be its own domain referenced from bookmap.] Another question was whether it was to be extension elements in bookmap shell.
- Eric; the intention was never for it to be added as extension element.
- Kris; but if you add an extension in a doc shell, that makes it available everywhere its base element is. OTOH, that's not the case if you've made it available only by putting it in .mod file, it's only available in certain situations.
- Eliot, thru 1.3, doing that is an implicit constraint and should be mentioned as a constraint, though no one cares...
- Kris; I know Robert has concerns about mapresources. When I started working on stage 3 proposal, it created pretty strong dependencies between bookmap and ditavalref, ??,,??
- Eric but ditavalref alreadly there in bookmap.
- Kris; it's in the shells distributed by OASIS, but it's not a hard dependency. until now, we haven't created hard dependencies between structural and domain modules.
- Eric; but bookmap already puts in hard dependencies; you have to put certain things in certain places. Because of the way the first layer of bookmap is structured, there are already certain dependencies.
- Kris; but if we're making changes to doctype shells that we haven't done before, we have to be aware of any dependencies and explain them, and how they're changing, it to our end users. None of the doctype shells I make for clients include ditavalref domain or mapresources. I think we need to have a dependency on the ditavalref domain, but we'll have to let people know it's required; and we need to have clear comments in bookmap shells saying if you delete the ditavalref domain, it will break.
- Eliot; I wonder if we should add something to our shells that lists the basic integrations that this shell must/should include...
- Robert; I don't think that's necessary; I think Kris's proposed comment is good enough.
- Eliot; okay, that's good enough for me.
- Robert; I don't feel as strongly about this; we've said this since 1.2, even if not in our shells.
- Eliot; as a practicioner, I also remove domains people don't use, but I'm also always adding constraints for things people don't use; if you remove the ditavalref domain, you need to also add a constraint to remove it from your content.
- Kris; you don't have to do a constraint if you remove a domain.
- Eliot; only if it's ref'd in a content model.
- Kris; this isn't something we need in the spec.
- Robert; right, Eliot, it's just a different type of tweak in the shell; it's not as easy as removing a domain, but adding a constraint is not a new thing.
- Kris; I'm not arguing against the new design. but just noting that we have to explain it carefully. Many practiciioners remove domains, but don't use constraints. so we have to explain to practicioners who aren't used to making constraints. We'll need new info in docs about what practicioners will have to do.
- Robert; yes, but not something that makes it seem as if it's new; it already exists for any constraint.
- Kris; but we probably do need a new example of a constraint. Also, we're creating a similar dependency on the glossref domain, if someone has a ref to a glossref. until 1.3, we didn't include glossaryref domain at all
- Eliot; don't we have a separate proposal to fix glossary domain?
- Eric; No, it got rolled into the bookmap proposal.
- Kris; I'm still unclear about our use cases wrt glossaryref and hardcoding a reference to one of its elements within bookmap.
- Eliot; I don't remember the history; if we have a way of referencing the glossary, it makes sense to have bookmap allow you to do so; but the problem with the glossary domain is that it doesn't include a mapref just for glossary as a whole.
- Kris; my tendency is, unless we have clearer articulation of use cases, we shouldn't include the glossary domain as a hard-coded reference in bookmap. That probably means re-doing to stage 2 proposal. Scott, can you think about that? I'll also go back and look at earlier bookmap proposals.
- Kris; my 3rd question is around the mapresource element; drivers were to clearly show in map where folks should put keydefs and subjectscheme; now, there are other ways to do that. Eric's clarification is 'this is a new domain' but do we really want a new domain eith a single element? Or do we add it to mapgroup instead? That would make mapresource available anywhere topicref is allowed. OTOH, if we define it directly in bookmap, there's no new domain needed.
- Eliot; I don't want it only available in bookmap, I'd want it in other maps.
- Eric; that was the rationale for putting it in its own domain. Adding it directly at the top of bookmap was to make it available to the whole map, for use of global keydefs, etc. But its main use case is to be able to define keys in a global area.
- Eliot; that, and putting it in frontmatter. It's not officially required to have a separate domain. if it was part of mapgroup, we would have to specifically do stuff, and it would also complicate shell configuration.
- Kris; I understand that there are compelling reasons for having this, but I still want to clarify; if we go ahead with a separate resource for mapresource:
1. what will we call it?
2. will we make it available anywhere else?
3. for bookmap, will we be integrating it as part of a new domain, but not including it as an extension element?
- Eliot; mapresource has the same doc reqs as for ditavalref. For the domain name; I'd call it mapresources domain, and integrate it in at at least the techcontent map, if not base map.
- Kris; I agree with putting it in techcontent. Any other thoughts?
- Scott; I think it's useful to have those resources at top of a map; as to whether it needs to be in its own domain, not sure why
- Kris; would this be a base domain domain, or techcontent domain?
- Eliot; base
- Scott; agree
- Eliot; thinking about it, I think it should be an extension element; if you have chapters in a book, you'd want mapreosurces as first child of each chapter.
- Kris; in which case, it makes sense to make it part of mapgroup, not separate.
- Eliot; could be separate, but also be in mapgroup.
- Kris; my sense that some folks didn't want to see it available everywhere topicref is available.
- Eliot; we talked about needing it at beginning, but I could make a case for needing it anywhere.
- Eric; so is there a to-do for me to update stage 2 proposal to say it will be added to mapgroup?
- Kris; I'll update stage 3 and update the stage 3 proposal. Eric, you and I can talk about it. I want to be sure we're clear about what we're doing on this.
[Kris and Eric will discuss]



8. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0

Stage two
(Lawson) Things you press (https://github.com/oasis-tcs/dita/issues/257) -- ON HOLD
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
- Eliot; waiting on review by Chris and Robert.
- Chris; I'll try to get to it this week.
- Robert; I'll also try to get to it this week.
- Kris; Eliot, if you get your reviewer feedback this week, when can you have it ready?
- Eliot; if reviews are in before Saturday morning, I should be able do it this week.
- Kris; dates?
- Eliot let's say 10/15.
(Evia) Column/row spanning in simpletable (https://github.com/oasis-tcs/dita/issues/292)
[no update; Carlos had left the call by this point.]
(Hudson) Allow example in more places (https://github.com/oasis-tcs/dita/issues/297)
- Scott; I've gotten review feedback from Kris and Carlos; waiting for feedback from Joyce
- Joyce; I did send it, but I'll resend.
- Kris; for stage 2, you only need a single reviewer.
- Scott; I can get a finalized version sent out for next week.
- Kris; it needs TC discussion, then we can vote the week after that.
- Scott; shoud be ready for discussion next week.
(Stevens) New title-less topic (https://github.com/oasis-tcs/dita/issues/98)
- Dawn; this may need to die; it was for L&T, and since we've decided not to do L&T profile at 2.0, it's probably not worth doing.
- Kris; are you sure?
- Dawn; where it stands in my mind is that Robert had some ideas; they indicated that my proposal hadn't been going the right way.
- Robert; I know I had different ideas; but I thought we'd come to a decision that just allowed people to filter out the title.
- Kris; I think the important thing is your comment since we don't as a TC plan to update L&T at 2.0; we can certinly remove Dawn's name for this, and send it back to stage 1.
- Nancy; were there any non-L&T use cases?
- Eliot; yes
- Dawn; I think we should at least send it back to stage 1, and remove my name.
- Kris; so we'll send it back, and next week decide whether there are any non-L&T uses for it.


Stage three
(Kimber) Remove topicset and topicsetref (https://github.com/oasis-tcs/dita/issues/34)
- Kris; date for this?
- Eliot; 10/8
(Kimber) Resolve inconsistent class values for shortdesc, linktext, searchtitle (https://github.com/oasis-tcs/dita/issues/21)
[no update]
(Schengili-Roberts) Strong and em elements (https://github.com/oasis-tcs/dita/issues/107)
[Keith not on call]
(Burns) Remove lockmeta attribute (https://github.com/oasis-tcs/dita/issues/278)
- Bill; I'm just finalizing; will ready for 10/15 [Bill out next week]
(Anderson) Add output class to DITAVAL flagging properties (https://github.com/oasis-tcs/dita/issues/252)
- Robert; this is out this week to reviewers; will be ready for discussion when they come back; let's say 10/7
(Anderson) Remove domains attribute (https://github.com/oasis-tcs/dita/issues/217)
- Robert; 10/15, this also has a dependency on reviewers
(Eberlein) Revised bookmap design (https://github.com/oasis-tcs/dita/issues/29)
- Kris; I have to modify stage 2 and stage 3 proposal; hopefully I'll have an updated stage 2 proposal next week, and stage 3 by first week in November.
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
- Chris; I'll talk to my mgmt and get time for this; let's say by Thanksgiving.
(Nitchie) Add titlealts elements to map (https://github.com/oasis-tcs/dita/issues/16)
- Chris; also Thanksgiving.


[note to all proposal owners: when you send proposals out to reviewers, give them deadlines, based on your own.]



12 noon ET close


-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 1 October 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-10-03 16:12:12



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