| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 25 September 2018 uploaded
- From: Tom Magliery<email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 27 Sep 2018 00:10:37 +0000 (UTC)
Minutes of the OASIS DITA TC
Tuesday, 25 September 2018
Recorded by Tom Magliery
link to agenda for this meeting:
11 AM ET open
1. Roll call
Attendance: Robert Anderson, Deb Bissantz, Carsten Brennecke, Stanley Doherty, Kristen Eberlein, Maria Essig, Carlos Evia, Richard Hamilton, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Dawn Stevens
Regrets: Nancy Harrison, Bill Burns, Chris Nitchie, Eric Sirois, Keith Schengili-Roberts
2. Approve minutes from previous business meeting:
18 September 2018:
https://lists.oasis-open.org/archives/dita/201809/msg00036.html (Magliery, 20 September 2018)
Motion to approve: Kris
Dick Hamilton stepping down in October
4. Action items
14 August 2018:
Robert: Provide command-line equivalents for SourceTree actions in education session slide deck
21 August 2018
Kris & Robert: Perform the best edit of multimedia topics that they can do in time available; due 18 September
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC
18 September 2018
Alan: Review the TC list to make sure everyone who's new has access to DITAweb.
Alan: Perform a test run in DITAweb to ensure everything works; handle any issues with Congility before 28 September 2018
Tom: Update DITA 2.0 deadlines Wiki page (COMPLETED)
5. Subcommittee and liaison reports
6. LwDITA SC items
New version of "Lightweight DITA: An introduction"
https://www.oasis-open.org/committees/document.php?document_id=63958&wg_abbrev=dita (Evia, 24 September 2018)
https://lists.oasis-open.org/archives/dita/201809/msg00041.html (Eberlein, 24 September 2018)
VOTE: "I move to approve "Lightweight DITA: An Introduction" Version 1.0 Committee Note 02 and all associated artifacts packaged together at as a Committee Note and designate the HTML version of the note as authoritative.
Kris: I'm guessing we're not quite ready to vote?
Carlos: We'd rather move this to next week
ACTION: Carlos, Alan: Upload full package of LwDITA committee note to TC repository -- HTML, PDF, grammar files, DITA source, and sample files (all items listed on cover page of committee note)
LwDITA issues that spec editors want to promote for TC discussion
https://lists.oasis-open.org/archives/dita/201809/msg00037.html (Evia, 22 September 2018)
Kris: I think many of these may be handled by now but let's check
Carlos: Robert helped me yesterday and #2 hasn't really been solved. Maybe indeed the approach is to report this as a DITA OT bug. The absence of domains is preventing the info in a DITA topic to be conrefed by an XDITA topic.
Kris: The standard says processors should report a warning. But not only are you getting a warning but the conref is not being resolved
Alan: It's a mystery to me, Michael, Carlos, this is a common use case, conrefing a specialized element type from a general one.
Robert: There are good reasons -- the domains are so drastically different and there are some funky ones in LwDITA. We never actually say "don't resolve it". There should be a warning. Somehow you get the same error if you try to conref from a constrained task and a generalized task. But that's not a common use case. Most often if there are constraints in two document types they're the same constraint.
Alan: Thanks for the background.
Kris: Do we need any discussion about item #1?
Carlos: No, it's all fixed, and thanks to Robert for that.
7. Review of DITA 2.0 proposal deadlines
Robert: #18 Finished Stage 2 proposal, and don't remember who reviewers were (if I have any).
Kris: We need two.
Deb: I'll review.
Dawn: I can do it.
Kris: We need to move the 25 September date
Robert: Hope to be able to send to the TC by next week
Kris: Change the date for #105 redesign chunking?
Robert: Yes -- no realistic way to be done by Oct 2, please change to Oct 9
Kris: Eliot, checking on dates for 13 November, all still OK?
8. New item: Titleless Topics and Context-Independent Content
https://lists.oasis-open.org/archives/dita/201809/msg00029.html (Stevens, 18 September 2018)
https://lists.oasis-open.org/archives/dita/201809/msg00034.html (Swope, 19 September 2018)
https://lists.oasis-open.org/archives/dita/201809/msg00035.html (Hudson, 19 September 2018)
Dawn: The point is that there are situations where the topic title is irrelevant, e.g. in learning and training building exams. We had a stage one proposal to make a titleless topic type, but as I was making a stage 2 proposal I ran into doubts that this was the right approach. Title really doesn't become irrelevant until publication time. Perhaps a better approach is to do this with attributes. Any suggestions or comments as to why we still need a titleless topic type.
Kris: Thanks Dawn.
Scott: I agree with the simpler approach, I think it'll be easy enough to add the attribute rather than create a new topic type.
Kris: To be clear: the proposal is an attribute on title and another one on topicref to point to a topic and say ignore this topic in the publication?
Dawn: Yes, that's it.
Eliot: I think that would satisfy my desire to have topics indicate that they are inherently titleless. I certainly agree with the need for the specialized topicref. But having an attribute on title rather than a new topic type would work for the other part. Having a new topic type would be subtle at best.
Scott: I think the attribute for title would be a little more intuitive if it were something like "ignore=yes". Of course the default would be "no".
Eliot: That seems right, yes.
Robert: I find that a little unsettling. This hasn't been a requirement of ours and I don't have a strong opinion. I'm really unsettled by the idea of "ignore=yes" because the first thing that's going to come up is "how can I make that conditional". Maybe we could just allow filtering on titles?
Scott: You could use otherprops.
Robert: You can't today because we disallow that on title.
Tom: Could we think of a better name for the attribute?
Robert: Either way it still feels like filtering.
Eliot: It was never my intent that a topic not have a title. It needs some kind of title. But for purposes of presentation there are certain kinds of topics where the title is not useful. E.g. if the topic contains a single interaction and we want to aggregate those. I think the distinction is subtle because it's only a presentation time choice. As an information designer I want to be able to say this topic is one of those.
Kris: Just clarifying we're not talking about titltless topics, we're talking about topics where titles are not useful for rendering/publication.
Eliot: That's right.
Robert: I still keep thinking this is exactly what filtering is designed for. You can have a filtering attribute that says "in the learning aggregation use case this title is not to be used". This is a reaction to "ignore=yes". People will want it anywhere.
Eliot: That's one of the reasons I always thought of this as a specialized topic type. If we put the attribute on the title itself then I think Robert's correct.
Kris: Let's remember that titles occur in many other places besides mandatory titles of topics -- tables, figures, sections, ... How does all this address the multitude of other places?
Robert: I think in the other places that only allow one title people might ask to have more than one, which I would resist, but you can already define that today. In section it would immediately be used to allow multiple filterable titles.
Eliot: I have a requirement in some other documents to have filterable titles in figures and tables. I would like that option, too. Although it's not one that I would champion.
Kris: So what do we want to do here? Continue to next week? Are there other folks who have thoughts, questions, concerns?
Robert: I think the one case that Dawn described that this doesn't automatically handle is the idea of using this attribute on a topicref. You'd have to update your processor so it knows this filter value means don't render the title. So that becomes more of a manual task.
Eliot: The topicref mechanism as currently defined should be separate from any ability to filter titles directly.
Robert: Yes, that's not the same thing.
Kris: We will have two pieces -- what do we do in a topicref in a map, and what do we do from the actual topic. I also don't like the idea of an ignore attribute on the title. If we do go in the direction of an attribute it needs to be something clearly very specific "title-ignore" or something.
Kris: But let's move on for now.
9. New item: File name conventions in the grammars
https://lists.oasis-open.org/archives/dita/201809/msg00031.html (Magliery, 18 September 2018)
Tom: I just wondered if the filenames in all of the grammar files are inconsistent enough to be a bother, and if they are, whether it's of any interest to fix it. I don't have enough experience working with the grammars, but for those who do, does anyone have any comments?
Eliot: the inconsistencies are annoying, but not so painful that I feel like we really need to fix it. Wouldn't *mind* fixing if opportunity presented itself.
Kris: Changing them would affect a lot of people's specializations.
Tom: One reason I could think to do it was if it would help people learn easier.
Robert: I'm more annoyed by the directory structure than the file names themselves, would love to clean that up. Filenames themselves I wouldn't mind changing. Anybody with shells will need to at least update PUBLIC IDs to get DITA 2 going anyway. As long as you're using catalogs the filename is sort of irrelevant anyway
Eliot: Yes, if you're creating shells you should be using PUBLIC IDs or URNs
Kris: You still need to change the file names in the catalog
Robert: You shouldn't have your own versions of the OASIS catalog. The filenames are all kind of irrelevant. I would like to make them consistent. The one thing I don't want people to think is oh, we have to have these filenames.
Kris: I would love to streamline the directory structure. That path structure is a pain. If we want to move forward, what's the best way to do so? Would we want a proposal?
Robert: I think this is all under the covers, shouldn't need all the overhead. We have changed filenames in the past
Kris: Maybe we don't need formal proposal, but do need suggestions of what to change
Robert: Definitely need a github issue to track it.
Eliot: I can put together a list of inconsistent filenames. Currently the RNG generator assumes the current directory structure. It would definitely be good to have the TC fix that sooner rather than later.
ACTION: Robert: Make a github issue to track "Improve consistency of file names and directory structure of the DITA grammar files"
ACTION: Eliot: Make a list of inconsistent file names in the grammar files
10. Update from DITA 2.0 spec editors
DITAweb review of subset of element reference topics to open Monday, 01 October 2018
Elements that exist in both DITA and LwDITA
Kris: Still on track to get this going, assuming that DITAweb is working. It will not include the multimedia elements.
Alan: Is there a point person responsible for creating the package for DITAweb?
Kris: I will be the point person for that.
Alan: And it's not ready yet?
Kris: It could be ready in 5 minutes on my part.
ACTION: Kris: Provide Alan with information about the map (etc.) needed to create a DITAweb project for reviewing "LwDITA-subset" element reference topics
11. Continuing discussion: DITA Adoption Would Like to Expand the DITA 1.3 Code Examples
https://lists.oasis-open.org/archives/dita/201809/msg00011.html (Schengili-Roberts, forwarded by Eberlein, 11 September 2018)
Kris: Let's hold this until Keith is present
12. DITA users want more (and better) examples
https://lists.oasis-open.org/archives/dita/201809/msg00025.html (Eberlein, 18 September 2018)
Kris: Anyone present who was at the listening session last week? Any further information about this?
Scott: I chaired the session. We had 6 different writing groups represented. Regarding examples, 3 groups did say they refer specifically to the spec for usage examples. Some were not aware of other collections such as Thunderbird and were happy to hear about those. They still were in favor of seeing more useful/realistic examples in the spec. But also mentioned they wouldn't mind seeing perhaps some industry-specific examples. E.g. software or medical or manufacturing, where they could see some best practices that might not be appropriate for the spec.
Kris: Any other info about the listening session to share?
Scott: Those were the main points. There was a lot of information regarding what kind of features each group were using.
Kris: Any questions for Scott or Stan?
XX. Final items:
Kris: Do folks want to have prizes for participation in DITAweb reviews? Anyone want to volunteer anything
Eliot: I will volunteer a pound of homemade bacon, although I probably couldn't ship that outside the US.
Kris: I haven't done a lot of canning this summer, but I could do some and offer that up as well.
Kris: Well everyone think about this please.
Dick: I would be glad to offer some books, and I could ship them anywhere.
Kris: Thanks Dick.
11:50am ET close
-- Mr. Tom Magliery
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]