dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 30 April 2019 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Mon, 6 May 2019 11:57:05 +0000 (UTC)
Submitter's message
ActionItems:
1. Kris will talk to OASIS to set up new CN and new open source repo for tracking migration info for 2.0
2. Robert will update chunking proposal.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 30 April 2019
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Alan Houser, Scott Hudson, Zoe Lawson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens, Joyce Lam, Jim Tivy
Business
========
1. Roll call
Regrets: none
2. Approve minutes from previous business meeting:
09 April 2019
https://lists.oasis-open.org/archives/dita/201904/msg00023.html (Harrison, 23 April 2019)
moved by Kris, 2nd by Dawn, approved by TC
23 April 2019
https://lists.oasis-open.org/archives/dita/201904/msg00025.html (Harrison, 26 April 2019)
Attendance info added: https://lists.oasis-open.org/archives/dita/201904/msg00026.html (Eberlein, 28 April 2019)
moved by Kris, 2nd by Tom, approved by TC
3. Announcements:
none
4. Action items
21 August 2018
Kris & Robert: Perform the best edit of multimedia topics that they can do in time available; due 23 April: (COMPLETED)
- Kris; hoped to have this on agenda today, but OASIS server is slow; will do next week
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC: due 09 April Overdue
13 November 2018
Eliot: Test refactoring of grammar files; due 07 Mary
18 December 2018
Eliot: Investigate issue re earningAggregationsTopicrefConstraintMod.xsd; due 07 May
29 January 2019:
Carlos: Set up regularly scheduled calls between DITA 2.0 and LwDITA spec editors; due 26 April
- Kris; shall we select a day and time once a month
- Carlos; what is good for you and Robert
- Kris; wait for Robert to come one call
- Carlos; use one of their Weds SC mtg
- Kris; first weds?
- Carlos; looks like it will work.
- Robert; and we have one scheduled for tomorrow, 5/1
05 March 2019:
Alan: Update DITA 2.0 files for appropriate elements with LwD hint values for @format and create a pull request; due 23 April
Carlos & Alan: Select three element reference topics that exist in both LwDITA and DITA 2.0 for LWDITA and DITA editors to work on; due 09 April
- Carlos; done, see Github
19 March 2019:
Michael Priestley: Propose methodology/syntax for mapping DITA class and outputclass attributes to HTML class attribute (COMPLETED)
- [MichaelP will hopefully be at second half of this meeting and talk about this]
02 April 2019
All voting TC members: Look through 1.3 normative statements listed in Nitchie's e-mail: What's missing? What's duplicative? What's nonsensical? How should we mark them up so we can get a clean extraction to build a (non-normative by definition) appendix?
09 April 2019
Eliot: Does SVG zip file need to be in techcomm grammar folder?
Kris and Tom: Finish up any discussion about examples in ArchSpec files
Nancy: Review LwDITA e-mail threads; create a Wiki page to track items, so that we can ensure that all items have been discussed and resolved
Kris: Modify Wiki page for conference table to show all times (COMPLETED)
23 April 2019
Kris: Post on dita-users asking how many people use property tables (COMPLETED)
Robert: Update chunking proposal
- Robert; will do that today
5. New item: Information about migrating to DITA 2.0
https://lists.oasis-open.org/archives/dita/201904/msg00029.html (Eberlein, 29 April 2019)
- Kris; Zoe has offered to own this work. we have a few options;
1. we can do a non-normative appendix in spec, but there are a lot of disadvantages to this.
2. go with CN; advantage is it's authered in DITA, and we can update it as necessary.
3. use a wiki page; disadvantage; authoring is in native wiki syntax
- Zoe; I'm assuming that if it goes into spec, it takes a fair amount of effort to fix it?
- Kris; if it's in spec, it can't be changed unless we re-release the spec, at least 6 months.
- Tom; realistically, we'd never release a spec just to include migration information, so it would really take years...
- Kris; agreed.
- Zoe; where do CNs live?
- Kris; they live on the OASIS website; they're 'official.'
- Eliot; I think a wiki would be the worst by far.
- Scott; I agree.
- Tom; I agree too, but is a CN still too formalf/ What about a TC white paper? This is not normative information, just a helpful thing
- Kris; that's what CNs are supposed to be. As a TC, we can choose how we want to do it.
- Tom; then a CN's what I'd recommend, on the lightweight side.
- Eliot; I'm also thinking of having a migration site; that could have that kind of material
- Tom; that wuold be good, a Github repository.
- Kris; a CN has the advantage that people can set a URL to the location, and they will always get an updated version, never an old version. And it can have attached resources, scripts, etc. that we can provide.
- Eliot; I assume we'll already have a 'what's changed in the release' in the spec. So, from 'what's changed' we just point to the CN.
- Kris; right, we have material from stage 2/3 proposals on what is needed for migration, and it's already time to start sharing that. I think a CN is the best thing. A CN has some level of formality, but not including a public review unless we choose to do so.
- Robert; I think a CN is best; storing tools in Github, a CN could have resources, or it could just have a link to the latest migration tools on github.
- Kris; so the TC would distribute the CN - there's a OASIS repo for that - do we need a separate Github repo for migration?
- Eliot; I would think so
- Kris; and I think we would want that to be an open repo, so others could participate
- Robert; we could have the CN in one repo, and the tools in a different one
- Kris; so consensus is that written content is in a CN in our repo, any migration tools, scripts, would be zipped up in a separate open-source repository.
***ActionItem: Kris will talk to OASIS to set up new CN and new open source repo for tracking migration info for 2.0
6. DITA 2.0 stage three proposals
Vote
None
Continuing discussion
Issue #105: Simplify chunking
https://lists.oasis-open.org/archives/dita/201904/msg00016.html (Anderson, 23 April 2019)
- Robert; I haven't done that yet, not sure; I can do it for next week
[hold for updated spec proposal]
Initial discussion
None
7. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion
None
Request for feedback:
Issue #123: Properties table
https://lists.oasis-open.org/archives/dita/201904/msg00017.html (Anderson, 23 April 2019)
Update: summary of responses on dita-users
https://lists.oasis-open.org/archives/dita/201904/msg00027.html (Eberlein, 28 April 2019)
- Kris; we asked for feedback, I posted to dita-users, summarized; eveyone thinks the content model is too restrictive, and they don't use it because it's hard to reuse. Does this give you, Robert, the way to handle this issue?
- Robert; I think we don't waste time doing anything complicated, just do something simple.
- Kris; or even drop it?
- Robert; it's a simple fix to add this content to the model for refsyn; if Jang wants something better, he can do it.
- Kris; does that work?
- Eliot; should we even maintain this element? since no one is using it...
- [some people do use it..., so we need to keep it in]
- Tom; my gut reaction was same as Eliot's; just get rid of it.., but I'll go along with everyone.
- Robert; Michael, do you know anything about property table usage? They seem to be generally unused.
- Michael; fwiw, the original usage domains were for parameters to command line utilities; I don't have any particular insight into whether they were used.
- Robert; if we want to remove them, the other option is to turn them into a domain. It's hard to say if that is good for everyone; the argument for removing them is that people alsays complain about the total number of elements in DITA; this is 9 elements, so it gives idea of removing it.
- Nancy; so is the idea to remove it, or to remove it and put it in a domain?
- Robert; it's up to whoever decides to do the work. I don't know if IBM is still using it.
- Eliot; doing a search on templates, a lot of them do use this.
- Robert; and a lot of them don't work...
- Kris; I wasn't expecting this to lead to removing it.
- Robert; if it's going to be done, someone needs to sign up for it.
- Kris; ok
8. DITA 2.0 stage one proposals
New "normal if used" Value for @processing-role
https://lists.oasis-open.org/archives/dita/201904/msg00020.html (Kimber, 23 April 2019)
[hold for next week]
9. New item: Class values in markdown and HTML
https://lists.oasis-open.org/archives/dita/201904/msg00028.html (Eberlein forwarding for Michael Priestley, 29 April 2019)
- Michael; in 1.3, we have 2 ways to use class @; how simple can we make it for LwD? and how can we differentiate the DITA @class from DITA @outputclass using just @class? Although the definition of @class in HTML is fairly loose, CSS is much more restrictive; it has to start with [A-Z, a-z] and it can only have [A-Z, a-z,, 0-9, -, _]; so what's bare minimum we can put in there? We need to have a name, also if it's specialized from an ancestor, it must allow multiple values for class hierarchy so we can allow for cascading stylesheets. We Came up with a set of suggestions [see mail above]. This approach loses specialization and module name (e.g. 'mybook') so we're not kept from a naming collicion, but this is for HTML or Markdown; if you get naming collisions, it probably means you need to look at using DITA or XDITA. for simple generalization, like a conref across specializations, you can just compare tokens, they'll just be simpler. The logic stays true to DITA, The idea is to XDITA the same as DITA, and just alter HDITA and MDITA. The SC thinks this is a good direction.
- Eliot; I think you're on the right track. One question; if you don't have module names, you can't go from HDITA back to module, what's the point of having the info?
- Michael; you could go to DITA, it just wouldn't be fully normalized DITA.
- Eliot; but then class @ wouldn't be needed
- Michael; if doc is in HTML, and we want to move into an XML instance, we won't know if a given para is generic, or specialized without some guide; once you've normalized, XML gives you full class name.
- Eliot; I think it's good to not have full grammar in HDITA and MDITA stuff. also I would prefer to use underscore rather than hyphen as you recommend.
- Michael; I agree.
- Tom; my concern is that a single class @ has been split into multiple tokens, which could end up getting re-arranged. what happens if they appear in an order we don't expect?
- Michael; whenever it's two elements, the sequence will be editable. so the question is not 'are we letting them edit the sequesnce?' The question is whether they're going to do it in a less accessible way; so that's the value of pushing it into @class; people know how to do that. It's a risk that they could screw up; if we have a multilevel specialization, and they order things wrong; it will matter if they try to do a generalization operation, or if they trya cascade that respects the order of the @ values. I think it's a risk, but not a huge risk.
- Tom; if they're publishing to a process that knows to look at rightmost DITA class@, they will get wrong style.
- Michael; exactly, but how likely is that to happen, and how likely is it they'll make an error if we make it harder?
- Tom; could there be a single token, in HDITA or MDITA, that represents whole @class hierarchy? [But I don't see that as permitted by CSS guidance rules...]
- Michael; e.g. in my 'prologtitle'
- Eliot; I notice it's missing 'title' in HDITA
- Michael; but the h1 is fixed to that mapping, so it doen't need to be explicit.
- Eliot; I see.
- Tom; despite my suggestion, I'm ok with this proposal.
- Kris; I think it's a good approach to doing something complicated within narrow boundaries.
- Michael; I appreciate giving us the leeway to do this; LwD is a narrow little world. doing some weird stuff; think we can make it work
- Kris; so is there consensus?
- Michael; including dash to underscore
[agreed]
10. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; updated date for redesign chunking
- Robert; not yet; need proposal reviews to come back
- Kris, shall we make that an AI?
**ActionItem: Robert will redesign chunking prop
21; Eliot; I've been trying to upload those all morning, and OASIS won't let me
34; Eliot; same thing, website is flaky
- Kris; got email from OASIS, implementing a new portal; by next week we might have new interface
107; Keith, move to end of may
Other:
STC meeting is next week, who will be there and not on call?
[Carlos, Deb, Alan, Tom, Dawn]
-Kris; I won't cancel next week's call, but please send mail early if others besides anyone needs to send regrets.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]