| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 27 February 2018 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 5 Mar 2018 23:12:07 -0800 (PST)
My apologies for the delay; I thought this had gone out last week after I wrote them.
1. Bob will commit his stylesheet schanges to Github.
2. Robert will work with Eric on bookmap proposal.
Minutes of the OASIS DITA TC
Tuesday, 27 February 2018
Recorded by Nancy Harrison
link to agenda for this meeting:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Richard Hamilton, Nancy Harrison, Alan Hauser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Eric Sirois, Bob Thomas, Don Day, Jim Tivy
1. Roll call
2. Approve minutes from previous business meeting:
20 February 2018:
https://lists.oasis-open.org/archives/dita/201802/msg00071.html (Harrison, 23 Feb 2018)
moved by Kris, 2nd by Dick, approved by TC
New TC members: None
4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
19 September 2017:
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
30 January 2018
Anderson: Stage two proposals for issue #18: Make audience, platform, product, otherprops into specializations
- Robert; not yet, but should have some time after this mtg
12 February 2018:
Thomas: Stage 2 proposal for issue #13: Split base and technical content
- Bob; need more time for this.
13 February 2018
Kris and Bob: Fix style sheets to produce OASIS-requested formatting changes (IN PROGRESS)
[see item later on agenda]
20 February 2018:
Kris: Ping OASIS about review for LwDITA committee note (COMPLETED)
Kris: Respond to Stephan Gruber on dita-comment list (COMPLETED)
26 February 2018:
Kimber: Stage 2 proposal for #34: Remove topicset and topicsetref
- Eliot; I'm behind, let's move it out to 3/13
Kimber: Stage 2 proposal for #21: Resolve inconsistent class values for shortdesc, linktext, searchtitle
Eliot; same as above; move it out to 3/13
Nitchie: Progress, stage 2 proposal, or withdraw issue #8: Add a new vocabulary element for inclusion of external XML and text markup (COMPLETED)
Nitchie: Stage 3 proposal for issue #27: Add multimedia domain
Sirois: Stage 2 proposal for issue #29: Modifications to bookmap design (COMPLETED)
5. "LwDITA: An Introduction" committee note
New package: https://www.oasis-open.org/apps/org/workgroup/dita/document.php?document_id=62491&referring_url=%2Fkws
Public review requested on 14 February 2018
15-day public review announced on 23 February 2018: https://lists.oasis-open.org/archives/dita/201802/msg00069.html
- Kris; public review was announced. Does the LwD SC want to publicize this review?
- Carlos; there has been some publicity on Linkedin and on Twitter. We don't want to get feedback thru wrong channels...
6. dita-comment e-mail
Guided Authoring with Lightweight DITA
https://lists.oasis-open.org/archives/dita-comment/201802/msg00000.html (Stefan Gruber, 12 February 2018)
https://lists.oasis-open.org/archives/dita-comment/201802/msg00003.html (Eberlein, 27 February 2018)
7. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
TC admin provided list of cover page corrections on 06 February 2018
Source changes implemented:
https://lists.oasis-open.org/archives/dita/201802/msg00036.html (Eberlein, 09 Feb 2018)
Style sheet changes needed:
https://lists.oasis-open.org/archives/dita/201802/msg00040.html (Eberlein, 13 Feb 2018)
- Bob; I was out sick for a week, so a number of fiascos brewing, will try to get something done within next week.
- Kris; work is largely done on PDF side; if you check it in an I can look and maybe get someone to work on html
***ActionItem; Bob will commit his stylesheet schanges to Github.
8. DITA 2.0 stage two proposals: Early preview
Issue #29: Modify bookmap design
https://www.oasis-open.org/committees/download.php/62594/29-Bookmap-update.html (Sirois, 26 February 2018)
https://lists.oasis-open.org/archives/dita/201802/msg00079.html (Anderson, 26 February 2018)
https://lists.oasis-open.org/archives/dita/201802/msg00080.html (Kimber, 26 February 2016)
https://lists.oasis-open.org/archives/dita/201802/msg00082.html (Swope, 26 February 2016)
Eric gave an overview of his proposal (see above for details).
- Eliot; I had some confusion over bookmapresources; what's it for? Do I create a specialization of that instead of using it to get a topicref?
- Eric; yes, it's the placeholder; essentially a stopgap; allows add'l info to be added to bookmap but not break the processing.
- Eliot; one of bookmap's main problem is that metadata isn't complete; solution is to just fix bookmap; why add a new specialization?
- Eric; we could add a new bookmap, I couldn't add topicref, because that would add other issues, so I added a hook...
- Kris; I'm a little confused here also. The proposal has some main changes to bookmap; 1) allow keydefs, 2) add ditavalref, 3) anchor for specializations. I'm confused on what is the intersection between resources and keydefs.
- Eric; the suggestion was that keydefs should be a domain.
- Kris; and the rationale for that was?
- Eric; because that was a requirement in the discussion.
- Eliot; but there's no reason to be bookmap-specific. We need a wrapper element but no reason that it has to be bookmap-specific.
- Eric; but we don't need it for any map but bookmap.
- Eliot; yes, we need it in every map.
- Robert; sounds as if there are 2 different design ideas in play, -> confusion. If the design goes beyond keydefs, then it's something else.
- Eric; the suggestion was to create it as a domain, so I needed a hook.
- Robert; I'm not sure about that. I don't think we need a hook; we just need a container for holding keys. In theory, we can just put it into bookmap without a hook.
- Eric; so it needed a domain.
- Eliot; even if it's in a domain, you can just add it to bookmap.
- Scott; I thought we'd have a generic wrapper that holds whatever we need, and it could contain keyrefs, subjectschemes, etc. to put in
- Eric; we can't have ditavalrefs in anything, or it won't apply to whole book.
- Eliot; what if we put a generic container that then constrains content?
- Robert; the only way to find a container useful is if it allows mapref, since I'd have all my keydefs in a submap; I don't want to copy every keydef into the bookmap. if you have mapref, you can get stuff in there. Part of this is wrt your goal of minimal touch, so we don't confuse current processors. But when we jump to 2.0, they will have to change, and so they will have to adjust to this. There needs to be guidance, but processors will have to change.
- Eliot; I would prefer to have ditavalref follow bookmeta, and be repeatable.
[Robert, Kris agree with this]
- Eric; OK
- Eliot; also, ditavalref needs to be allowed in every bookmap child
- Eric; as long as they allow topicref, that's OK.
- Kris; are there any that do not?
- Robert; maybe...
- Eric; I will make sure to check all of those...
- Robert; there are a couple of empty ones - figurelist etc. - it's probably not worth adding it to those.
- Eric; I'll just concentrate on immediate children from frontmatter to backmatter.
- Kris; any other comments? I just want to check; do we want to get rid of the idea of a hook/anchor and just have a place for metadata?
- Robert; I would like the resources element to be able to contain anything, for keydefs, metadata, etc.
- Kris; it could be called bookmapresources or map resources. Robert; can you help Eric a bit so next time the proposal comes up it will be ready for next design?
***ActionItem Robert will work with Eric on bookmap proposal.
9. DITA 2.0 stage two proposals: Initial discussion
Issue # 08: New element for inclusion of content from external files
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/62589/Issue08-include.html (Nitchie, 25 February 2018)
Chris gave overview of proposal (details in proposal).
- Chris; I wanted a common ancestor for coderef, svgref, and mathmlref that would be transclusion not reference. modeled loosely on XML transclude. an inclusion rather than a pointer. There's really no reason it couldn't be used to include DITA content, but we don't want that, so I'm including processing hints. but requiring an error on having parse="xml" anywhere except in foreign.
- Eliot; we want to absolutely require that any DITA conotent must be set as XML.
- Kris; I'm good with that.
- Robert; otherwise we've re-defined conref without the safety features we've put on conref.
- Chris; the other aspect of the proposal is that I'm allowing for custom values in @parse, so custom procesors could incorporate other things (such as CSV as a simpletable) though that just opens the door to confusion. I think we want to give implementors as much rope as makes sense. but others may not agree.
- Robert; I think it makes sense here. The 'possible' use cases here make more sense than others have. In the case of the coderef element, Open Toolkit has allowed you to specify encoding and lines in a file.
- Tom; can we now have svgref/mathmlref only allowed within foreign?
- Chris; svgref and mathmlref are only allowed within foreign or a specialization of foreign; coderef is only allowed within a codeblock.
- Tom; this introduces an element that we strongly recommend should only be used for specialization.
- Eliot; in the previous case, we were allowing a hook to require spec. this is like foreign, an element.
- Kris; this is fixing an original design flaw.
- Tom; right... It took time to realize that all 3 elements were the same kind of element. And this doesn't help authors much, mostly implementors.
- Robert; it could be useful to authors as well. The previous situation spurred the abuse of xref.
- Eliot; this is saying 'xref is only meant for navigation', 'include is only for inclusion'.
- Tom; it will help me clarify my powerpoint slides on types of links
- Eliot; there's been concern about allowing a more general translusion process; offering a feature with a lot of power, without having designed it completely to enable that use.
- Kris; is there a concern about going back to processors to support additional values for @parse?
- Eliot; the use case are clear, but there are other ways you could get the same result by modifying conref, rather than this.
- Kris; maybe we should hold for add'l discussion next week
[continued to next week]
10. DITA 2.0 stage two proposals: Continuing discussion
11. DITA 2.0 stage two proposals: Vote
Issue #36: Remove deprecated items
https://lists.oasis-open.org/archives/dita/201802/msg00059.html (Eberlein, 19 Feb 2018)
https://lists.oasis-open.org/archives/dita/201802/msg00077.html (Eberlein, update on 26 February 2018)
The TC voted to move the above proposal to stage 3:
Tom made the motion, 2nd by Bill
Results of voting:
'yes' votes: Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Richard Hamilton, Nancy Harrison, Alan Hauser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Eric Sirois, Bob Thomas
'no' votes: none
[proposal #36 will move ahead to stage 3]
Kris asked about stage 3 reviewers; Keith, Nancy, Robert, and Stan volunteered.
11:58am ET close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]