dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 5 March 2019 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Thu, 7 Mar 2019 23:27:04 +0000 (UTC)
Submitter's message
ActionItems:
1. Alan will update files for appropriate elements with LwD hint values for @format, and make a pull request against DITA 2.0 branch in spec repository.
2. Carlos & Alan will pick 3 topics to go over; next week we'll take up questions of creating a sub-module for LwD.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 5 March 2019
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Eric Sirois
Business
========
1. Roll call
Regrets: Deb Bissantz, Keith Schengili-Roberts, Dawn Stevens
2. Approve minutes from previous business meeting:
12 February 2019:
https://lists.oasis-open.org/archives/dita/201902/msg00056.html (Harrison, 21 February 2019)
Moved by Kris, 2nd by Bill, approved by TC
19 February 2019:
https://lists.oasis-open.org/archives/dita/201902/msg00057.html (Harrison, 21 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00058.html (Harrison, 23 February 2019)
Moved by Kris, 2nd by Tom, approved by TC
3. Announcements:
New TC members: None
4. Action items
21 August 2018
Kris & Robert: Perform the best edit of multimedia topics that they can do in time available; due 18 September
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC
13 November 2018
Eliot: Test refactoring of grammar files
Spec editors incorporate changes from DITAweb review (Significant progress, very near to completion)
18 December 2018
Eliot: Investigate issue re earningAggregationsTopicrefConstraintMod.xsd
22 January 2019
Kris and Robert: Schedule meeting to plan moving forward on implementing complete DITA 2.0 proposals
29 January 2019:
Robert, Tom, Scott: Review examples that Stan suggests adding to DITA 2.0 spec
- Kris; Tom, can you try to move on that for next weeks meeting?
- Tom; will do
Kris: Set up regularly scheduled calls between DITA 2.0 and LwDITA spec editors
- Kris; this is reassigned to Carlos.
05 February 2019:
Kris: Add fix to 'xmlnamespace' topic to list of things to fix in 2.0.
12 February 2019
Tom: Schedule meeting with Robert and Scott to go over the additional examples Stan proposed for DITA 2.0
Kris: Move formatting guidance from intersection topics to an appendix topic (COMPLETED)
19 February 2019
Kris, Eliot, Robert: Meet to go over high-level changes needed for Committee Note stylesheets (COMPLETED by Eberlein and Kimber)
Alan and Tom: Have functional stylesheets for DITA spec (PDF and XHTML) by DITA NA conference
Kris: Ensure that any changes to spec stylesheets for rebranding are in GitHub (COMPLETED)
- Kris; folks, please look at any of yours above and close them out if possible.
5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; Scott, what about the changehistory proposal?
- Scott; it's been merged into Eric's bookmap proposal, so it should be deleted.
- Eliot; wrt proposal for removing inconsistency in class @s for shortdesc, linktext, searchtitle; this is pretty straightforward. It will update map versions to align with topic versions; map processors will need to be fixed to align as well.
- Eliot: wrt 'deprecate or remove copy-to...' proposal, I sent it to Robert and Chris
- Kris; can we get those reviews back on that by next week? (Chris not here..)
- Robert; for my proposals on the list, I'll set new deadlines of next week.
- Eric; I'll aim to get stage 3 proposal for bookmap by May; it has to be after DITA/NA
6. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion
Issue #34 Remove topicset and topicsetref
https://lists.oasis-open.org/archives/dita/201902/msg00064.html (Kimber, 26 February 2019)
Eliot; the proposal is just what it states; as far as we know, no one is actually using these tiems, which is why we're removing them. Does anyone have questions?
[none]
Kris; This falls in the area of cleanup and removing elements that are duplicative and don't add value.
Issue #21: Resolve inconsistent class values for shortdesc, linktext, and searchtitle
https://lists.oasis-open.org/archives/dita/201902/msg00065.html (Kimber, 26 February 2019)
- Eliot; here, the issue is that we have elements with the same local name, but different @class values, in both map and topic. Solution is to use a single class value whichever they're in - we've chosen to take the one from topic rather than map. The fix requires that map-specific processing will be updated to be the same for these elements as topic-based processing, since the map @class is changed to match topic @class.
- Kris; both of these are queued up
7. DITA 2.0 stage one proposals
Accommodations in DITA 2.0 for LwDITA
https://lists.oasis-open.org/archives/dita/201902/msg00059.html (Houser, 24 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00062.html (Anderson, 25 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00063.html (Houser, 25 February 2019)
- Kris; Alan's mail isn't exactly a proposal, but will affect DITA spec
- Alan; LwD sees that some DITA processors may support LwD as well, so we're proposing to drop value hints so a DITA processor can identify XDITA, MDITA, HDITA content. The DITA spec already uses some hint values for @format; "print", "text", etc.
- Robert; this could be a proposal, or it could fall into the class of stuff too trivial to be a proposal. Since we already mention things like 'text', we should also mention LwD tokens. LwD folks should define exactly what they are.
- Kris; I'd favor not treating this as a formal proposal. Can we consider this an AI on updates to the format topic?
- Alan; that works for me; I can just modify those files. and make a pull request
***ActionItem: Alan will update files for appropriate elements with LwD hint values for @format, and make a pull request against DITA 2.0 branch in spec repository.
8. Continuing item: Reworked intersection topics; "Rendering expectations" and appendix topic for "Formatting expectations"
https://lists.oasis-open.org/archives/dita/201902/msg00053.html (Eberlein, 19 February 2019)
- Kris; i though we'd decided to move formatting expectations to appendix, and move much of processing expectations (PE) to rendering expectations (RE)/ But the meeting minutes don't make that clear. So I want to check that TC likes this method and wants to go forward.
- Alan; and you've done this and it's in the spec source?
- Nancy; did anything end up still in PE?
- Kris; not in these topics, I think...
- Tom; only in navtitle element.
- Kris; and what about that entry?
- Tom; I think it should stay in PE
- Nancy; navtitle can be used for other things, not just rendering, so I agree with that.
- Eliot; I agree, this is processing, not rendering.
- Kris; so we do have a clear sense about when PE is still valid, as in navtitle; are we, as a TC, happy with these changes?
- Alan; putting very minor bits of info in a different place that a user has to go to and find doesn't make me happy.
- Kris; we have 3 choices;
1. we can remove the formatting info from spec entirely.
2. we can put them all together in an appendix, as I've done.
3. we can include FE in topics, but every time we do, we have to note that they're non-normative.
- Alan; can that be unobtrusive?
- Kris; no, by OASIS rules it has to be very obvious, in a parenthesis under the section title.
- Alan; are there other sections that are defined as non-normative?
- Kris; as I remember; appendices, examples, and notes are the only sections defined as non-normative.
- Alan; what kind of note is required?
- Kris; OASIS suggests a parenthetical statement in bold right at the beginning of the section.
- Alan; my comfort would still be higher in that approach.
- Kris; I'd like to wait till we have Chris on the call.
- Robert; as an implementor, I prefer the appendix route; it makes it easier to reference. And it makes me more confident that an implementation will follow all the FEs. As an end-user, I can understand wanting them to be in the individual topics, but that's not our primary audience in the spec.
- Kris; I'd tend to agree, given audience for 2.0 spec. This is parallel to our topic on recommendation on DITA in translation.
- Alan; OK, this isn't a gatekeeper for me, but...
- Kris; we'll leave this open till nexxt week, and hopefully Chris will be there.
9. Stylesheets
OASIS has agreed to build actual style specifications, with our help
https://lists.oasis-open.org/archives/dita/201903/msg00012.html (Eberlein, 04 March 2019)
Best format for developing specification? DITA --> Word, or Excel?
Volunteers?
Updates on committee note:
Now runs on DITA-OT 3.3 (both PDF and HTML5)
Alan has submitted a pull request
Update on spec:
Runs only on DITA-OT 2.5.4 (PDF)
- Kris; OASIS has agreed to create actual style specifications so they can't just change Word templates without letting us know. Is there a way to do this? We could do it in DITA, or we could do a spreadsheet. I'ce done a first cut wrt CNs. Alan, could you look at that and give me any changes you think it needs? I put it in a DITA topic in the stylesheet repository; please look and let me know if I missed anything.
- Alan; so it's a DITA topic that contains formatting specifications?
- Kris; yes, though it doesn't cover padding.
- Alan; I don't have a lot of tolerance for formatting directives that don't support the brand or support the user. e.g. is there a heading rule or not? Pick it or not, but don't worry about it.
- Kris; the reality is that when we generate stuff, we have to align with OASIS stylesheets, which mostly deal with presentation on thte cover page.
- Tom; I have a suspicion that OASIS will start caring about this as soon as they see an issue that says 'font is left up to TC'.
- Alan; so this willl be like a contract that we can write.
- Kris; historically, we've had ridiculous churn over cover page presentations.
- Robert; our goal is to avoid that last-minute churn.
- Kris; practically, they've historically given us a Word template which we reverse engineer. But we never catch every detail in our template, and they don't catch everything we miss, until we actually publish, or they tweak their template without telling us. Doing a style spec will be work on our part, but it will reduce our work downstream. I need volunteers for a draft specification for spec output. Tom and Alan, you're doing stylesheet work on the spec; if you can get it to run reliably, that would be good. Can you also work on specification rules?
- Tom; I'm not an expert, but I can sign up as another pair of eyes
- Alan; I can help;
- Kris; The CN runs fine on DITA-OT 3.
- Alan; but the CN didn't run till you identifed source of compatibility.
- Kris; I think it's a separate problem with preprocesing on numbering.
10. Continuing item: Proposed review of DITA 2.0 elements to LwDITA components
https://lists.oasis-open.org/archives/dita/201902/msg00042.html (Evia, 09 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00047.html (Eberlein, 12 February 2019)
- Carlos; we looked at Kris's template, and started to review it wrt using it for LwD. Without a doubt, there will be many instances where we'll need to put conditional processing in 2.0 topics in order to use them for LwD. If you look at message attached to this item, it's a list of elements borrowed from 2.0 draft and the beginning of an analysis of what will work and what won't work, and how to propose a solution. To do this, we may need to work directly on the 2.0 topics and add stuff that will be hidden in 2.0, but show up in LwD spec.
- Kris; we need to figure out where to move forward. At end of day, LwD spec is published by the DITA TC, not by LwD SC. So the TC has to be very clear about what it will mean to have alignment between 2.0 and LwD.
- Carlos; Alan and I have been discussing one way this could work is if I work on 2.0 topics, on the same source. At first, we were only going to make changes to shortdesc, but if we're going to have alignment, we need to be working on same files. Maybe we need to have both specifications in the same Github repo.
- Robert; I agree you need to be looking at the topics; doesn't make sense to be doing reuse without actual reuse. We talked about setting up a sub-repo for LwD, but it's a bit abstract. For the moment, whatever you want to change, you need to conosult with Kris and me. I don't know what filtering will need to take place yet. could use subjectscheme. So we need some basic prep work.
- Kris; I suggest 2 things:
1. set up a joint call with LwD ans 2.0 spec editors, and look at a few gnarly LwD topics, with an eye to developing filtering ideas.
- Carlos; that sounds good. we're going for the same types of audience, but our readers will be looking for different things.
- Robert; I also note; all your changes should be put in using a pull request; that sounds standoffish, but that's the way github works.
- Kris; and I also do pull requests, which do validation. I've never changed spec files directly; I always use pull requests.
***ActionItem Carlos & Alan will pick 3 topics to go over; next week we'll take up questions of creating a sub-module for LwD.
[for more related LwD issues, see agenda items #11-16 on today's agenda, archived in agenda site listed at the top of these minutes]
11:58am ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]