OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Groups - DITA TC Meeting Minutes 14 March 2017 uploaded

Submitter's message
ActionItems: no new items this week

Minutes of the OASIS DITA TC
Tuesday, 14 March 2017
Recorded by Nancy Harrison
link to agenda for this meeting:

1. Roll call
Regrets: Maria Essig, Keith Schengli-Robert

2. Approve minutes from business meeting on 7 March 2017:
https://lists.oasis-open.org/archives/dita/201703/msg00011.html (Nancy Harrison, posted 10 March 2017)
moved by Kris, seconded by Scott, approved by TC

3. Announcements:
New TC members: None

4. Action items
23 August 2016:
Kris: Get TC inStance of DITAweb updated with 1.3 DTDs; restore sync with SVN (IN PROGRESS)
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 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
21 February 2017
Kris: find someone from the iiRDS working group to come to TC meeting and do presentation.
Kris; in progress
Kris: Organize meeting with Robert, Kris, Dick, and Dawn about workflow/admin practices for errata 02
Kris; in progress
28 February 2017
Tom: Make sure his minutes from Feb 28 include all the data; some of it didn't come through. -- look for MARKUP (COMPLETED)
Robert: update 2.0 proposal process to include info on removing something from a shell without removing it from the specification.
Robert: update 2.0 proposal process to include info on referencing deprecated elements/attributes, in case of backwards compatibility issues.
07 March 2017:
Tom: Locate instructions for DITA 1.3 instructions for stage 3 reviewers and proposal ownere (COMPLETED)
Robert: Update DITA 2.0 process to include link to instructions for stage 3 reviewers / reinforce idea that reviewers need to validate proposals
Kris: Clean up agenda re DITA 1.3 errata 02 (COMPLETED)
Kris: Organize meeting with Dawn, Carlos, Robert, Nancy, and Chris to discuss high-level design for DITA 2.0 spec
Kris; no change on items from 7 March

5. Continuing item: DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
Eliot; updated grammar files for errata 02

6. New item: Overall fixes for bookmap for DITA 2.0
https://lists.oasis-open.org/archives/dita/201702/msg00033.html (Eric Sirois, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00035.html (Eric Sirois, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00038.html (Kimber, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00040.html (Nitchie, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00048.html (Swope, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00050.html (Eberlein, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00051.html (Kimber, 21 February 2017)
- Eric; we've had a number of inquiries about requests for bookmap, mostly about creating keydefs. Folks want at least that for 2.0. I'd like to know whether we want to do a bookmap 2.0, or do we want to upgrade the old one and keep it around for compatibility? or both?
- Amber; With many of my clients, the metadata that they want for a deliverable is only available in bookmap; they'd like to have a metadata domain that isn't dependent on bookmap. And there are things missing that are only available in xnal.
- Kris; not sure how to characterize their pain points. Is it actually a problem with bookmap, or is it simply a need for a separate metadata domain?
- Amber; The pain is that they have to use bookmap for deliverables that aren't books.
- Kris; is that just wrt xnal?
- Amber; no, there are things in bookmap metadata that they need for other deliverables.
- Don; I've had the same issues with creating things like white papers, and having to use bookmap.
- Eliot; I'd echo Amber on the metadata issue; it needs to be in its own domain. Also, the metadata is inadequate, e.g., no ISS, no license that isn't copyright, (as in 'creative commons' license). And the specialized topicref types aren't in their own domain; that's a real problem, because they can't use them outside of bookmap. This issue is somewhat lessened by 1.3 feature of allowing inclusion of structural domain elements from other topic types. We also need to have different submap types to specifically define things like a chaptermap and a partmap.
- Chris; Also, you can't include a bookmap as a reference from another bookmap; and you can't have a chapter before a part
- Kris; can we talk a bit about who developed bookmap and what the design goals were?
- Nancy; It was developed by Erik Hennum, and I worked with him on it. The goal was to include the kind of bibliographic informatin that DocBook already had, so we took DocBook as a guide. We also wanted to have elements for referencing organizations and people, and we looked at the XNAL standard to see what they had. We took a subset o the items in the SNAL standard and included them, in some cases with slightly different definitions, in the XNAL domain.
- Stan; just fyi, it ws a plugin long before 1.1
- Kris; so it looks like we have a number of pain points, Eliot, you had a pubmap that was targeted for 1.3 but got dropped; is it worth looking at, or should we just look at a redesign for 2.0?
- Eliot; what I did in pubmap was design bookmap as i would have wanted it. There's one domain for maprefs and one for topicrefs, and one for metadata. There are separate map types for different book items. I don't know that it's appropriate for 2.0; it's much more complex than most people need, because it's meant for publisher, with covers, logos, etc.
- Chris; yes, it's a bit complex...
- Eliot; We want to break things down in separate domains; a la L&T. That would largely satisfy me; we could also make some backwards-compat additions to the current bookmap to add keyrefs in the right places.
- Kris; what changes can we make to bookmap? Do we want to deprecate bookmap?
- Bob; one thing we could do is reengineer bookmap so it's at least using domains for chapters, etc.
- Eliot; the challenge is that doing that breaks bookmap entirely.
- Chris; make bookmatter optional, [ask Chris what he said as minimal]
- Kris; do we need to gather more pain points or do we know what the primary ones are?
- Eliot; I would hope that among us, we've experienced pretty much all of them.
- Kris; i think this is mostly a consultant poin point, not so much an authoring pain point.
- Amber; and that's because 1) people get help from consultants, 2) for things like not reusing bookmaps from bookmap, they make architectural choices to go with other types of map.
- Scott; and getting cover pages, etc. is pretty painful and hard to do; cover logos and things like that.
- Amber; and teams that feel the most pain are small companies, not big compaines, and some of them just walk away from bookmap; people have kind of given up on it. so they beef up map to meet their needs.
- Deb; I'm using bookmap, and I'm not seeing a lot of the issues or concerns; there might be more advanced things if I knew about them. I think if we did 2.0, I'd just drop my chapter maps into the new one, and port the metadata.
- Dick; one possible addition to this topic; it's not just bookmap, e.g. xrefs and the ability to have more control over the style of xrefs. something like the docbook xref style might be nice.
- Kris; I think that's a different topic.
- Dick; Leigh's book was done with bookmap and we did have those issues, not for the writer but for us in publishing it. And we solved them with Eliot's pubmap package.
- Chris; currently, bookmap is part of techcontent package, not the base. For 2.0, do we want to have it in the base rather than in the techcontent? We've talked about de-emphasizing non-base parts of the spec and focusing on the base, but I think we need to have this in the base.
- Kris; if we're moving to having new map design as part of 2.0, in order to better meet publishing demands, with a more modular design, I'd see a lot of utility in putting it in the base.
- Nancy; I think we should leave the old one in techcontent, and have a new one in the base.
- Stan; I second that idea
- Eric; I agree, the old bookmap would just become a plugin, they could use it with a few tweaks.
- Bob; but if we go forward, the old one should be loosened up a bit.
- Kris; we probably have thousands of bookmaps with these issues that would be helped by loosening up. One problem we haven't mentioned yet is around glossaries.
- Kris; should we have a discussion of glossary around pain points with bookmap, or does it need to be separate?
- Eliot; it needs to be separate.
[there was general concurrernce in the TC with Eliot]
- Amber; I think that glossary generation presents real challenges; sometimes folks want a glossary, but they don't want to have to use bookmap to get it. But when they look at a regular map, they don't see a glossary as an option there.
- Eliot; right, we need to move glossary into a domain and have it available to any map.
- Don; glossary is a standard collection; the method for calling it should be Standardized.
- Kris; so to summarize, 2.0 should include a new map type, part of base, more modular, using domains for metadata. We'd like to leave bookmap as part of techcontent, but include keydefs. Are we ready to create stage 1 cards - one new card for fixing the old bookmap, and one for a new map type for the base?
- Dawn; there will be a relationship between those 2 cards; people would be working on both at once; it may be a benefit to divide those tasks differently. It still seems that if we can loosen the old bookmap up, we should consider things in tandem.
- Robert; I'm wary of introducing new map types because people are already confused by the many maps we have.
- Kris; are there people interested in doing design work on this?
[pretty much everyone]
- Kris; at some point, we'll need to know who are the real champions.
[continue next week]

7. Continuing item: Formal work on DITA 2.0
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
Review of cards on project page
Stage one (in progress)
[see agenda item #6 above]

8. Continuing item: Listening sessions
Portland, OR - March 8, 2017 -- Update?
Research Triangle Park, NC
Austin, TX
Report on session 8 March 2017 in Portland OR:
- Amber; we had pretty good attendance (13 in the room and 4-5 remote); also had a good videoconference, which was recorded. The conversation was genial, though someone did mention that working with DITA feels like 'Stockholm Syndrome' :-) I was disappointed that a number of local companies using DITA didn't participate. The next step is to look at Keith's notes, sync with mine, and update his spreadsheet.
- Nancy; People were concerned at the ramp-up time, and learning curve, especially for small companies; they also mentioned how hard it was to get DITA style sheet design specialists (even for big companies).
Amber; they mostly just wanted more resources for learning how to do information architecture and stylesheets; many of them praised Leigh's book (one of them had a copy with them).
- Scott; the main themes weren't issues with the standard itself; the pain points mostly related to the processing side. But that means that they're mostly things we can't address as a TC. One thing they did mention was a need for more real-world examples. They also asked for ablity to nest ditaval conditional information.
- Amber; there was some discussion of desired (generic 'emphasis' tag) and 'undesired' (highlighting domain) elements. Most of them specialize to disallow most of the highlightling domain.
- Kris; what do you mean by 'nested ditaval files'?
- Scott; they have conditions that are common to many publishing situations, and they want to be able to reuse a set of conditions across those situations.
- Kris; so they want the ability to reuse components of ditaval?
- Scott; if they have a bunch of scenarios that control PDF rendering, they want to set them across all PDF without copying and pasting them.
- Kris; so their requirement isn't addressed by the ability to have multiple ditavals in 1.3?
- Scott; they're mostly using 1.2 because the tool chains haven't caught up.
- Nancy; that was actually one takeaway; migrating to a new releasae is seen as a huge hurdle; not one of the companies in the group is using 1.3, except for one that only started with DITA within the past year.
- Robert; 'nesting ' ditavals should be do-able

12 noon ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 14 March 2017

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2017-03-14 11:09:16

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]