dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 14 August 2018 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 20 Aug 2018 08:13:43 +0000 (UTC)
Submitter's message
ActionItems:
1. Robert will prepare command line material for Github tutorial.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 14 August 2018
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Carsten Brennecke, Bill Burns, Kris Eberlein, Maria Essig, Richard Hamilton, Nancy Harrison, Scott Hudson, Eliot Kimber, Tom Magliery, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Bob Thomas, Jim Tivy
Business
========
1. Roll call
Regrets: Carlos Evia, Deb Bissantz, Chris Nitchie, Stan Doherty
2. Approve minutes from previous business meeting:
7 August 2018:
https://lists.oasis-open.org/archives/dita/201808/msg00022.html (Magliery, 10 August 2018)
ATTENDANCE https://lists.oasis-open.org/archives/dita/201808/msg00027.html (Eberlein, 14 August 2018
Kris moved, 2nd Nancy, approved by TC
3. Announcements:
New TC members: None
4. Action items
31 July 2018:
Kris: Communicate with Joe Pairman about metadata attribute proposal for DITA 2.0
- Kris; need to track down Joe's new email address at SDL.
5. Spec editing needs
GitHub and GitHub tools education
Rescheduled for Thursday, 16 August 2018, 2-3:30 PM ET
- Kris; this time works for Eliot, Tom, Robert, and me
- Nancy; can it be recorded [since I can't make that time]?
- Kris, planning to record; we know not everyone can do it.
- Scott; is it posted?
- Kris; not yet, but it will be; please save thet time on your calendars.
- Nancy; going forward, will that time be a standard time for folks working on the spec to meet?
- Kris; probably only for me, Robert, and Tom, maybe Carlos...
Rough agenda for training
https://lists.oasis-open.org/archives/dita/201808/msg00031.html (Eberlein, 13 August 2018)
- Kris; [reviewed above email] any questions/comments?
- Eliot; looks like the right agenda to me; I have material for first items.
- Kris; I have material for Sourcetree, and expect Robert will cover command-line.
***ActionItem: Robert will prepare command line material
- Kris; Robert and I will pull together material on pull requests/p.r. messages. I think we should have common conventions for working on the master branch.
- Tom; it might be really good to work thru an actual example, working on a example topic, so we could do a real change and see it through.
- Kris; that's a good idea, we might have to settle for trivial but useful change. Also, we've simplified the workflow since slide deck I sent Tom last week.
- Robert; we don't have to make a meaningful change, if we're not going to merge it into the repository.
- Kris; the last item is on workflow for maintainers; we're looking at people who are familiar with Git, or have access to the DITA repositories - me, Robert, Bob, Carlos - we want to be clear what we're doing with master branch, and what kind of Q&A maintainers need to do when updating repository.
- Nancy; what about Atlassian IDs?
[Kris; capture that in minutes]
- Tom; wrt Atlassian ID; I did set up an Atlassian acct to work in SourceTree; I didn't have to do anything about it.
- Kris; we might need a guinea pig to help us out with that.
6. RNG local element definition
https://lists.oasis-open.org/archives/dita/201808/msg00020.html (Sirois, 10 August 2018)
- Kris; Eric, did you get an answer?
- Eric; yes, it creates a mess for DTDs, so we should avoid it; we don't need a discussion on it.
7. DITA 2.0 stage one proposals
Continuing discussion
None
Initial discussion
Add another element to booklist to aid in auto-generating revision history
https://lists.oasis-open.org/archives/dita/201807/msg00050.html (Hudson, 25 July 2018)
- Scott; 1.3 intro's changehistory; what's missing is element that signals that element to the processor, need another element to do that; can't use 'changehistorylist' since it's already taken, but
- Eric; my 1 question is, where does it ned to go, frontmatter only? or also backmatter? if one or both, will affect where it shows up in elements list.
- Scott, to be more flexible, should be in booklist, depends on company style whether they want it in front or backmatter, prefer to have it in both.
- Eric; that makes it easier. wrt amendments, is there a particular reason why they would never be in front of book?
- Kris; think that moves us into item #8, so let's finish this item.
- Dawn; i think Scott's idea is good, we're having to buld that kind of element for clients
- Robert; i think only question is why we would want to deprecate an element we just added to 1.3?
- Kris; that's for next item
- Scott; on this item, should it be a separate proposal, or part of
- Eric;'s bookmap proposal?
- Kris; depends on agenda item #8...
8. Bookmaps and booklists
https://lists.oasis-open.org/archives/dita/201808/msg00023.html (Sirois, 13 August 2018)
https://lists.oasis-open.org/archives/dita/201808/msg00024.html (Hudson, 13 August 2018)
https://lists.oasis-open.org/archives/dita/201808/msg00025.html (Magliery, 13 August 2018)
https://lists.oasis-open.org/archives/dita/201808/msg00026.html (Hudson, 13 August 2018)
https://lists.oasis-open.org/archives/dita/201808/msg00029.html (Eberlein, 13 August 2018)
- Eric; main issue is in DTD world,
[Kris; ties back to dita-comment, about making changes to amendments]
using elements in multiple locations, always has to same content model; in RNG side, have capability to define local content models for elements; where elements have diff content models, depending on where they occur within other elements
- Kris; stefan wanted to move amendments from being direct child of back matter to a child of booklists.
- Eric; because it behaves in the same way as stuff in booklists. but in original booklist design, amendments only available in backmatter, so if we keep that, we cant' move it to booklists, since that's in both front and backmatter. So what do we do about this. Why are amendments only in backmatter? if so, we shouldn't make that change, but if we think they could be in either, we can't move to booklists.
- Eliot; i have publications where amendments are in front matter. we have generally been moving from more to less constrained
- Bob; still trying to understand how amendments is different from Scott's proposed revhistorylist...
- Eliot; one of my publications is CAO regs for FAR; have amendments that represent new laws, separate from editorial changes, amendments reflect actions of legislators, revhistory is actions of editors.
- Robert; if you look at spec, defines it as 'auto-generated' ; gen'l expectation is if you have a processor, it will be auto-generated. Another option is to just add elemetn to front matter, and don't worry about putting it in frontmatter
- Eric; if we just add it to rontmatter, better for backwards compatibility. counterpoint is if we add to booklist, it's cleaning things up a bit.
- Robert; amendments vs revhistory seems very specialized, that could be handled with specialization.
- Eric; could create soemthing based off of
- Robert; using element without ref'ing something, makes a generated list, make it with ref does something diff.
- Eric; so, leaving it up to processor?
- Kris; so is href or xref required on an amendment.?
- Kris; so, did we decide to not make backwards -incompat changes in 2.0?
- Eric; if we decided that, better to add amendments to frontmatter, which woud solve Scott's req as well; so amendments with no href -values behaves like revhistory, otherwise, does something else
- Robert; that would be my preference at this point. makes least churn
- Scott; wrt naming convention; wonder if we want to keep lists as part of name
- Kris; think this doesn't involve introducing a new element; but just making amendments available in frontmatter, with a dual/use implementation, w/ or w/o href/xrefs.
- Kris; hearing gen'l consensu on adding this to 2.0 as part of bookmap, addresses both stefan's and Scott's proposals.
Other
-----
- Kris; one other item; any more thoughts on what we want to do for a new pubilcation map? comments? I think our original design goal was to have a map germane to many sorts of publications, a map that's workable for publications in general, so we can leave 'map' as a basis for specializations or for use as chapter maps.
- Eliot; I think your analysis is correct.
- Kris; what do folks think about this? We do need at least one major change in functionality to provide motivation for people to migrate.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]