> Eliot: Add @format to image in grammar files
> 4. Eliot will fix the grammar files to change the default behavior for setting up complex table
I have submitted a pull request for both of these items.
From: <firstname.lastname@example.org> on behalf of Nancy Harrison <email@example.com>
Date: Tuesday, October 10, 2017 at 12:18 PM
Subject: [dita] Groups - DITA TC Meeting Minutes 10 October 2017 uploaded
1. Bob will build HTML output for Errata 02 and notify TC about it.
2. Nancy will review the new output for Errata 02.
3. Kris will propose a formal schedule for Errata 02, including TC and public review dates.
4. Eliot will fix the grammar files to change the default behavior for setting up complex tables.
5. All TC member should review last version of LwD Committee Note
Minutes of the OASIS DITA TC
Tuesday, 10 October 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
Robert Anderson, Carsten Brennecke, Bill Burns, Kris Eberlein, Maria Esrig, Carlos Evia, Richard Hamilton, Nancy Harrison, Alan Hauser, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Dawn Stevens, Bob Thomas
1. Roll call
2. Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201709/msg00035.html (Nancy Harrison, 26 September 2017)
[hold till next week, to include attendance)
New TC members: None
4. Action items
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 July 2017
Tech comm subcommittee: Consider whether to make proposal to allow steps to nest a stage 1 proposal
8 August 2017
Kris: Request GitHub repo for L & T subcommittee
19 September 2017:
Kris: Build errata 02 and ask OASIS to check the cover pages
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
26 September 2017:
Eliot: Add @format to image in grammar files
- Eliot; not done yet
Robert: Add @format to image in element reference topic
- Robert; not done yet
- Kris; Eliot and Robert, please handle these this week
Kris & Carlos: Identify topics in the LwDITA committee note that need a focused review (COMPLETED)
5. tcworld and DITA Europe
How many voting members will be out on 24 and 31 October?
[A number of TC members will be at either/both tcworld / DITA Europe; Kris will check and see whether we can get quorum for our calls on Oct 24 and/or 31. Looks like we should be able to meet at least the 31st.]
6. Lightweight DITA committee note review
Link to Wiki page: https://wiki.oasis-open.org/dita/LwDITA-committee-note-schedule
Link to (updated) PDF, DTDs, sample files: https://www.oasis-open.org/committees/download.php/61594/LwDITACN%2320.zip
Link to DITAweb: https://ditaweb.com/oasis-dita
Summary of DITAweb review comments
Plan for vote on 17 October
- Kris; summary of comments and are you on track
- Carlos; SC had a call yesterday, we were able to address most of the comments. We've noted status on most items, Alan wrote to TC about how our response. There's a new draft of CN out, (#21) ready for comments by TC.
- Kris; is this last iteration in Kavi?
- Alan; not yet, but ww'll have it in this afternoon.
- Kris; so we're on track for approval by 10/17. All TC members should look at the latest version, so that we can have a roll call vote at next week's call.
- Carlos; What is our process for setting up a public review?
- Kris; OASIS does the process; they have very precise guidelines for dealing with responses when it's a spec, but I don't know off-hand about what their response process is for CNs. We really ought to publicize this to get optimal outreach;
- Carlos; LwD SC is already preparing for that; we have set up outreach for a number of non-current-DITA communities.
- Kris; what about current DITA users?
- Carlos; we're reaching out to those thru various avenues as well
- Nancy; we can certainly use tcwork and DITA Europe to publicize it
- Alan; I have a tlal there about LwD, can use that.
7. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
- Kris; no new errata 02 items; do we have updates on style sheets?
- Bob; yes, some progress on HTML output.
- Kris; are they finished?
- Bob; no known outstanding issues, so maybe...
- Nancy; is there a built version?
- Bob; is markup in github up-to-date
- Kris; except for recent changes to frmat image
ActionItem: Bob will build HTML output and notify TC about it.
ActionItem: Nancy will review the new output.
ActionItem: Kris will propose a formal schedule for Errata 02, including TC and public review dates.
7a; NEW Errata 02 item from Robert - table accessibility attributes;
- Robert; In trying to implement some of the new 1.3 table accessiblity @s for more complex tables, I found a problem. The issue is that based on the language in the spec, if you want a header in a column other than the [default] first column, you use the colspec element. However, the default set in the grammar files for colspec means that every cell of every table becomes a header. To fix this, we need to remove the default in the grammar files. The spec language seems to be OK.
- Kris; any objections to moving forward with that fix for Errata 02?
ActionItem: Eliot will fix the grammar file to change the default behavior for setting up complex tables.
8. Items from recent listening sessions held by Adoption TC
https://lists.oasis-open.org/archives/dita/201710/msg00014.html (Notes by Stan Doherty, forwarded by Eberlein)
- Keith; we had a set of 3 virtual listening sessions, Europe, east coast, west coast. The results are in Stan's notes (above link) for key points. I also sent out (to the TC list) the poll results from the sessions. There were typically from 30-60 people per session; the poll results are quite intersting.
It seems to me that European folks working with DITA are technically ahead, using 1.3 and using advanced technical features, maybe because they came to it later. From Stan's comments: a couple of users mention metadata standards, they'd like to see better ways of representing metadata within content, without mentioning specifics. A lot of the feedback was of the usual; better tools, low cost entry tools, interest in LwD, plus someone wanted to see a 'mediumweight' DITA (as opposed to LwD). Wrt the poll results, about 45% had heard about LwD, but were undecided about whether to go forward with it. Other items that case up often were requests for easier ways to specialize, better examples in documentation, and a better, more usable spec,
- Kris; some of the comments aren't germane to TC, but have more to do with Adoption TC. but the metadata issue, and ease of specialization, are definitely on our turf.
- Kris; please everyone take a look at these notes.
- Keith; Definitely, take a look at the polling results. Seems to me that 'making metadata in DITA more robust' has a connection with the upcoming release of the IIRDS 'standard', there will be talks about that at tcworld. Another interesting result of the polling: between 6-13% (depending on location) don't use any version control. "we pray a lot"
9. DITA 2.0 stage one proposals: Discussion
New map for publications in base
Previously discussed at the following TC meetings:
14 March 2017
21 March 2017
Summary from Nancy: https://lists.oasis-open.org/archives/dita/201709/msg00023.html (Harrison, 19 September 2017)
Kris; ready for more discussion?
[no more input at this time]
10. xml:lang for filtering
Continue discussion from 19 September 2017
Hold for Chris Nitchie to be present?
- Chris; we left off last time with a general consensus that filtering on @xml:lang was a bad idea, though I couldn't understand exactly why.
- Nancy; was the idea to use @locale instead?
- Eliot; even @locale isn't precise enough; you need some combination of xml:@lang, @locale, and @region, especially in Europe, but it's almost never the case that just lang will stand for locale and region as well.
- Chris; but sometimes it's more narrow than that.
- Eliot; but that's a very narrow use case; it doesn't extend to the general case, and people don't realize that, so we don't want them to be able to hang themselves.
- Chris; we could make it simple to do simple things, and harder to do harder things. but we're not letting them do the simple things...
- Eliot; as stadards designers, do we have the responsibility to keep users from hurting themselves?
- Chris; I bristle at arbitrary guardrails; 'you can't do this because you don't know what you're doing.'
- Robert; I agree with your sentiment, but I'm conflicted about this. In most places I'm against 'guardrails'; this is the only one I feel differently about, though it's hard to defend my feelings. In every other case, with filtering values, the filtering is expressing 'who' is going to see the content, rather than a native property of the text itself; in some places those qualities overlap, but there are many places where they don't. We've heard about problems with this.
- Chris; I'd vote to allow it, but I won't lie down on the tracks for it.
- Eliot; Robert and Chris have now convinced me that it might be a good thing...
- Kris; I'm still profoundly uncomfortable at filtering on xml:lang.
- Robert; the real issue is, what is the spec going to say or not say? Right now, we say 'these are the filtering @s' we don't say 'you can't flag on xml:lang. So partly it's a question of explicitly addressing filtering on xml:lang; is it conformant or not?
- Chris; I'd consider it a win if we continue to be silent on it.
- Nancy; can we address this by explaining this better in the spec?
- Kris; our coverage of xml:lang certainly isn't so great.
- Robert; if 2.0 changes such that xml:lang is the only @ that's explicitly non-filterable, then we'd need to add a bunch of stuff to the spec.
- Chris; I'm very much against explicitly not allowing vendors to filter on xml:lang.
- Eliot; we can't justify explicitly disallowing filtering on xml:lang; but we could put in a non-normative appendix explaining the issues. But disallowing it would be untenable.
- Kris; these are interesting questions about setting guardrails or not; is it patronizing or does it serve a certain purpose? We have a very wide user base, experts and novices. If we move in the direction of opening everything up, a lot of the novices will sink. The listening sessions contain very conflicting requests.
- Eliot; I'm not sure that the user community will ever be able to use DITA as originally intended, which was that everyone would specialize it to their needs; now it seems that everyone wants to be able to use it OOTB.
- Kris; all we can do is give more explanation.
- Eliot; the issue is that neither I nor anyone else can provide the information that would be necessary; because no one is getting paid to do it.
- Kris; can't deny that.
- Robert; do we continue to say 'these are the only items available for filtering' or not?
- Kris; that's never been on the 2.0 list. So should that be on the 2.0 list?
- Eliot; radu and jarno have framed the issue by their actions, forcing us to respond.
- Kris; what was the original rationale for limiting filtering @s?
- Robert; basically, to set up guardrails, expecially on @rev.
- Kris; there are also questions of interoperability; interop is facilitated by having designated filtering @s.
- Robert; I'm not sure of that; interop comes down to what your app supports, anything you filter on, app has to support.
- Tom; if apps have to be ready to support filtering on any @, apps will have to be more intelligent.
- Kris; there's also the interop issue of moving content from one company/environment to another, especially moving content from an environment where all filtering is supported, to one that doesn't, or vice versa.
- Robert; that doesn't concern me as much, because an environment where all filtering is supported (e.g. SDL) has left the spec, so is non-standard.
- Kris; what happens between content from company A and B if they make very different decisions?
- Robert; people are already using filtering on @s we don't recommend; we can't stop them.
- Chris; we can say; these are the profiling @s, you shouldn't use others
- Robert; we say "if you're doing profiling, must (not normative) use profiling @ or a specialization of @props". So it's not a normative MUST, but a 'must'
- Kris; for 2.0, we also need to look at spec normative language like that.
Kris; LwD materials will be updated, please take a look at those, for a vote on the 17th.
11:58 am ET close
-- Ms. Nancy Harrison