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 26 September 2017 uploaded


Submitter's message
ActionItems:
1. Eliot will add @format to image element in grammar files.
2. Kris or Robert will update spec to reflect addition of @format to image.
3. Kris and Carlos will identify areas in LwD CN that require particular attention from TC members in review, and communicate those areas to TC.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 26 September 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
TBD


Business
========
1. Roll call
Regrets: Chris Nitchie


2. Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201709/msg00026.html (Nancy Harrison, 20 September 2017)
https://lists.oasis-open.org/archives/dita/201709/msg00033.html (Eberlein, 26 September 2017)
moved by Kris, 2nd by Alan, approved by TC


3. Announcements:
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 (waiting on info from subcommittee)
- Kris; we need user IDs for people who will be moderating that repo (i.e., Dawn and Amber)
- Dawn; will get those to you.
19 September 2017:
Kris: Build errata 02 and ask OASIS to check the cover pages
- Kris; will do this next week
Alan: Set up Wiki page to track LwDITA committee note progress (COMPLETED)
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
- Kris; will do this next week.
Nancy: Summarize previous discussions about a new DITA 2.0 map and post to list (COMPLETED)
Robert: Send e-mail to list about new errata 02 item (COMPLETED)


5. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02 - https://wiki.oasis-open.org/dita/dita1.3Errata02
New items: Image missing @format
https://lists.oasis-open.org/archives/dita/201709/msg00025.html (Anderson, 19 September 2017)
Kris moved to include this, no objections, approved by TC
***ActionItem: Eliot will add @format to image element in grammar files.
***ActionItem: Kris or Robert will update spec to reflect Eliot's changes


6. DITA 2.0 stage one proposals: Discussion
New map for publications in base
https://github.com/oasis-tcs/dita/issues/28
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; we've discussed this item before, and have a summary from Nancy; basic idea is for a new map, within the base part of the spec, oriented for use beyond just printed or PDF books, and designed with domains so pieces could be reused in various ways.
- Eric; one of the points made in the discussion was that Eliot's d4p plugin might serve as a good basis, but his current version includes way too much stuff for people to need as an intro publishing map.
- Eliot; yes, I was thinking more that d4p would serve as a model for how to use domains in a map, rather than the monolithic style of bookmap.
- Scott; and that would work well.
- Stan; I thought everything in the summary made sense in terms of logic. would this be a doc shell, or ingredients that people could put together on their own?
- Eliot; we'd need someting as a starting point.
- Kris; I think we'll need a starter shell, though we'll have to think hard about what we provide in it.
- Nancy; i was thinking of a somewhat self-documented shell, with commented out sections describing what to include.
- Kris; we'll have different audiences; implementors who want to use various pieces, others who'll want to use the OOTB shell.
- Bob; another thing to do is refactor current the bookmap implementation, so that parts could be reusable in the new map.
- Robert; that would be nice, but my worry is that if we create a new map, we don't want to break the old bookmap in the process; it's so widely used that breaking it would cause a lot of pain.
- Scott; could we use topicref directly, so we could reuse existing topic-level maps, and apply an @ to indicate what kind of container it is (chapter, appendix) at an element level, so as to make it something that makes it easier to integrate submaps?
- Eric; yes, rather than forcing a chapter map, use topicref, but associate an @ to make it a chapter. Our clients want to have a single map for all publications, rather than specialized ones.
- Scott; we can't use topicref directly in bookmap today; it has to be within a chapter or appendix.
- Robert; it makes me very nervous to add @s for format designation.
- Scott; it's more wanting to use topicref in a base map.
- Eliot; I'm not sure I follow the requirement.
- Kris; nor am I.
- Scott; we now have maps that use topicref, but in bookmap you can't use them directly.
- Nancy; as I remember, our previous discussions included the idea of being able to use topicrefs directly in the new map.
- Eliot; I don't understand Scott's point; use of topicref doesn't imply any requirement on the topics referenced.
- Robert; his point seems to be focusing on markup changes, rather than structure.
- Kris; we need to ground this more in terms of use cases. We've talked about fixing fundamental design flaws in bookmap, i.e. portioning things into domains
- Scott; well, use cases that come to mind are 1) ability to easily define cover content, 2) create glossaries and glossary terms, 3) link mgmt (reltables can get really large and unwieldy).
- Robert; all of those make sense as requirements, but I don't know how they relate to having a generic topicref.
- Kris; I think those requirements speak to the need for better-defined domains to help people create documents that incorporate useful parts of bookmap; new domains, to be included in map, to make it more useful.
- Kris; one issue is that peole are dependent on DITA-OT and its use by bookmap. With a new map, wil we have to completely redesign the PDF2 processing?
- Eliot; we shouldn't work on that; it's too full of cruft.
- Robert; but it's what we've got, and what most people use, and nobody's writing a new one, so if we break it, we're breaking something most people are using. We can redesign domains all over the place, but better to not break bookmap and its processing completely.
- Eric; for the existing bookmap, there are some very small changes needed; adding ditavalref and keyref, etc. Maybe we just need the existing map with more plug&play features available.
- Kris; Eric, how much are your suggestions related to making map maintenance within CMS easier?
- Eric; not so much, some clients just don't want to have multiple maps based on publication; they just want one map that they can reuse for different methods of publication.
- Kris; I see people doing that now, using bookmap for that, and using submaps with it,
- Eric; most people do, but then they use it for webhelp also.
- Kris; in designing a new map, we have to think about other formats, besides books, webhelp, and epub,
- Eliot; I understand wanting to have a single map, but in many cases, requirements for different publications are really different.
- Kris; I don't think you'll ever get away from needing different maps for differenet things.
- Eliot; Scott/Eric, are you talking about a single map type, or a single map instance?
- Scott; mostly a single map type, but sometimes a single map instance.
- Eliot; a single instance just wouldn't work, though hopefully we could have a single map type. The only way to enable a single map instance would be by creating a map type that's a union of all requirements, but then you wouldn't have any constraints on anything, so that might not work either. Trying to have a single map instance isn't really feasible.
- Kris; it's a pipe dream; 'one map to rule them all'; it would end up being unusable for authors, content architects, CMS implementors, and link managers.
- Bob; I do have one questions about metadata requirements. I'm wondering if there's a way in 1.3 to store a digital object identifier associated with a publication.
- Eliot; you'd would have to specialize your own.
- Bob; We probably should include one in metadata, and backfill to bookmap
- Stan; I would opt for flexibility over universality; that would help small companies that have to integrate with big ones after an M&A.
- Kris; what do you mean by that? providing additional map domains that would have things like metadata or glossary, to be incorporated?
- Stan; yes, that's what I mean.
- Kris; I don't think a map that includes everything works well,
- Scott, but doesn't scoped keys provide some of that if you put it in a single map?
- Eliot; it doesn't provide structural flexibility.
- Kris; this will take a while to flesh out, just in terms of synchronizing our vocabulary. Right now we're not actually all understanding each other when we put out requirements.


7. Lightweight DITA committee note review
Link to Wiki page: https://wiki.oasis-open.org/dita/LwDITA-committee-note-schedule
Link to PDF, DTDs, sample files: https://www.oasis-open.org/committees/download.php/61594/LwDITACN%2320.zip
Link to DITAweb: https://ditaweb.com/oasis-dita
- Alan; we kicked off the Ditaweb review on Friday (1 day later than scoped); some folks have already reviewed the CN - thanks. There's an issue with way it's uploaded; inline comments aren't enabled, only topic-level comments. We can leave it this way, or try to sync and create a version with inline comments enabled. I've heard from some reviewers that it's an issue, and I'm working with Congility to try to fix it. For now, we'll leave it, if we have to, we'll add inline comments.
- Kris; if we can get Congility to sync with SVN, we can set up a new review; problem is that we don't have a lot of ID @s to provide hooks for inline comments; so we'd need to run a script to add IDs. If someone has a script to generate IDs, we could use it.
- Bob; wrt my comments; I could also furnish a PDF with them.
- Alan; I've generated a report of the comments as they exist now, in case things crash.
- Kris; does Mekon/Congility have such a script?
- Alan; I can think about it
- Tom; is there a specific format we need for these?
- Kris; just a unique ID
- Tom; maybe XMetal's autoID feature would do that; I'll check after the call...
- Kris; what are the deadlines?
- Alan; current deadline is Oct 3 (one week from today), we need help from everyone, since the next step is public review.
- Kris; I'll look thru the CN and identify areas where we need focus, to send the right message to the public.
***ActionItem; Kris and Carlos will identify those areas


8. xml:lang for filtering
Continue discussion from 19 September 2017
Hold for Chris Nitchie to be present?
[hold till Chris is present]


Other:
Keith; I sent out a list of listening session questions; wondering if anyone has any other questions to add.
[discussion of possible additional questions and changes to current questions]



12 noon ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 26 September 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-09-26 09:54:21



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