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 8 May 2018 uploaded

Submitter's message
ACTION: Kris to set up call with Robert and Carlos to talk about best ways to move forward on sharing content between the two specs (DITA and LwDITA)
ACTION: Eric to consider content of email (about in ) and report back to the TC
ACTION: Kris to make effort ensure that we have better coverage in the 2.0 spec of processing implications for ditabase, in particular that in the topic covering @href the example needs to be refined at the very least; and 2nd that we possibly add new language either in the discussion of the dita element or maybe in the processing language about how this should be processed.
ACTION: Robert to start tracking information about what we should do with shells in 2.0. Specifically start with putting glossref in bookmap.

Minutes of the OASIS DITA TC
Tuesday, 8 May 2018
Recorded by Tom Magliery
link to agenda for this meeting:

1. Roll call
Regrets: Robert Anderson, Nancy Harrison
Attendance: Deb Bissantz, Carsten Brennecke, Kris Eberlein, Maria Essig, Carlos Evia, Jang Graat, Dick Hamilton, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Jim Tivy

2. Approve minutes from previous business meeting:
17 April 2018:
https://lists.oasis-open.org/archives/dita/201805/msg00003.html (Harrison, 07 May 2018)
01 May 2018:
https://lists.oasis-open.org/archives/dita/201805/msg00002.html (Magliery, 03 May 2018)
Motion to approve both by Kris, second by Alan

3. Announcements:

4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
19 September 2017:
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
27 March 2018
Kris and Tom: Check errata 02 package against OASIS previous request for changes

5. CMS/DITA NA 2018 conference
Many TC members who attended were not present for the 01 May call: Brennecke, Eberlein, Evia, Houser, Hudson, Schengili-Roberts
Alan: nothing to add to last week's summary

6. LwDITA Subcommittee Report by Carlos:
Carlos: Last week the SC talked about how we had very positive response to LwDITA sessions, mostly in the Markdown side of things. There were no "mean" questions in my own talk. There was interest in tools; we in the SC tend to be distracted and forget about our goals of writing/developing a spec. Alan and I had informal meetings with oXygen about what they have now and are planning. George proposed that MD core should become more tolerant of any MD that user wants to bring in.
I'm struggling to receive feedback from both new users and "haters". Trying to come up with a better way to process those.
We probably need to revise our high-level spec dev work because the LwDITA spec is going to be kind of experimental. Would be nice to be able to re-use LwDITA spec content in the DITA 2.0 spec.
Kris: Robert and you and I can talk about that offline.
Kris: If you're going to specify loose processing, what does that mean for the spec, e.g. the conformance clause?
Carlos: Obviously that's tricky, we want to beef up the spec for MD-extended. We don't have final resolution on this yet. May be something to think about.
Tom: "Liberal acceptance" is the wheelhouse of tools, not of the spec.
Alan: A problem is that tools for LwDITA just means "text editors"
Kris: This (how to foster liberal acceptance) has always been a problem for specs, one approach is to express the idea in an adjunct document
Kris: Carlos and SC, thanks for your work toward the specification

ACTION: Kris to set up call with Robert and Carlos to talk about best ways to move forward on sharing content between the two specs (DITA and LwDITA)

Jang: Even if the idea of core and extended MD is not going to fly it would be good if in discussions those two terms are reversed. The core should be the compliant stuff and extended should be anything that is extra
Carlos: I agree, maybe those aren't the best words to use.

7. DITA 1.3 Errata 02
Kris: Tom and I will take care of our action item to get this moving this week

8. dita-comment e-mails
Support wildcards in DITAVAL values
https://lists.oasis-open.org/archives/dita-comment/201803/msg00002.html (Radu Coravu, 14 Mar 2018)
Scott: Can see the usefulness from a user side, not sure about from a processor side
Chris: Doesn't bother me all *that* much, except potentially as a performance problem

https://lists.oasis-open.org/archives/dita-comment/201804/msg00000.html (Stefan Eike, 05 April 2018)

ACTION: Eric to consider content of email and report back to the TC

9. ditabase
https://lists.oasis-open.org/archives/dita/201804/msg00079.html (Jim Tivy, 18 Apr 2018)
Jim: We were looking at ditabase support in our product and we decided in the context of LwDITA ditabase doesn't make sense. Someone mentioned it was not a best-practice, so I wondered why we even have it; maybe we could cut it out of 2.0. I talked to many people at DITA NA and I came away with general idea that it's probably not something we're going to be seeing a lot of. People may be using it already for containers of topics but there are already so many others and the problem of combining topics is they don't perofrm as well in the tool if you have 10 topics in 1 file. CMSes tend to be file-based ... so I just thought at some point you're doing a disservice to the user.
Kris: I want to summarize use cases raised by folks
- aggregating small topics (e.g. message topics)
- conref library topics especially mixed topic types
- create a single topic shell wherever CMS specifies topic type
- migrating content
- ability to reference a specific topic directly within the top level topic
Kris: The question is should it be deprecated?
Jim: I would like to see a survey to see how people are using it, most of the use cases can be replaced by other ways of doing things.
Chris: We had this conversation already, I'm very sympathetic but I backed off. All of Kris's use cases can be done without the element. I backed off because there is exactly one use case where is the only current solution: referencing a ditabase document from a map without addressing a specific topic. The processing assumption is that ALL the topics from the document come in as siblings at that location. You can't do that with a root topic without introducing a level of hierarchy.
Kris: The ame is true for these very short message topics.
Chris: You could do that in a topic, that's not a compelling use case to me
Kris: Well it's the same thing if you're referencing that topic from a map
Kris: That is largely how ditabase has been implemented since the beginning
Kris: There is tons of ditabase content out there
Kris: This is something we have discussed and kind of closed before. Do folks want to re-open this discussion?
Chris: I do think there are spec language changes that need to happen. The @href topic strongly implies, although does not actually say, that without a fragment identifier a topicref references the first topic; this needs to be clarified. Also it needs to talk about processing expectations.
Jim: Is it well known that this references all topics?
Chris: It's been understood without being stated. But the PDF output has always only grabbed the first topic. That's where my misndeerstanding came from.
Eliot: My memory was that at least at one point, maybe 1.1 or 1.0, the spec said that the behaviour was different for HTML and print. That always bothered me. I could't find anything like that in the 1.3 spec.
Kris: I think we may have already captured these to-dos, but let's have an action item.

ACTION: Kris to make effort ensure that we have better coverage in the 2.0 spec of processing implications for ditabase, in particular that in the topic covering @href the example needs to be refined at the very least; and 2nd that we possibly add new language either in the discussion of the dita element or maybe in the processing language about how this should be processed.

Kris: Jim is that sufficient?
Jim: Yes, I think so. I agree that it would shock many people to get rid of it.
Kris: Should the Adoption TC consider a whitepaper on best practices?
(silence ... moving on)

10. Bookmap does not integrate glossref domain
https://lists.oasis-open.org/archives/dita/201804/msg00098.html (Kimber, 25 Apr 2018)
Kris: This looks like simply a correction of an oversight
Eliot: Yes. At the time glossref was created it was never added to bookmap
Kris: Some background: for 1.3 we did try to go through all the shells and talk about what domains should be in/out. For reasons of backward compatibility we did not remove any. But some shells do have some things that seem unnecessary (e.g. mapgroup in subject scheme). But we should maybe have more corrections to the shells for 2.0. This is also an opportunity to decide what domains should be OUT of shells.

ACTION: Robert to start tracking information about what we should do with shells in 2.0. Specifically start with putting glossref in bookmap.

Eric: It should be added in such a way that it not doesn't necessarily appear everywhere
Kris: So not as a domain substitution element
Eric: Yes

11. Fwd: DITA 2.0: Further Thoughts
https://lists.oasis-open.org/archives/dita/201804/msg00101.html (Shane Taylor, forwarded by Eberlein on 28 April 2018)
Kris: Many of these items are about the task topic, but also something about locktitle and key alternative definitions
Kris: I think the one about locktitle, don't we already have a stage one proposal - maybe from Eliot?
Eliot: Yes, that's mine to somehow improve the default values for locktitle
Kris: So I can respond that that one's already on our list
Are there other of Shane's points that the TC should consider?
Any volunteers to consider this email and report to the TC?
Eliot: With the key alternative definitions item it is not clear what he's asking for; he's not describing anything you can't do today
Chris: Not sure if it's this but I thought about defining key definition fallbacks in topics
Eliot: That would definitely be interesting, but I don't think that's what he's talking about here
Scott: He's talking about alternate image targets, but you can use combinations of profiling to accommodate that
Kris: Shifting to "context vs section", maybe some of these things are handled in general task rather than strict task
Scott: If you made that a generic section, then if you start using sections then you could only use sections. We'd have to drastically loosen the generic task model. I do know our users would prefer more flexibility.
Chris: We'd have to loosen the content model of in the core vocabulary
Scott: This could be done in 2.0 but it would be a massive change
Kris: Is anyone willing to respond in more detail to any of these points? Things we don't understand or are problematic?
Jang: I would be interested to investigate further especially the machinery task but also task from which it was created. I really don't know any implementations that are actually using that model.
Kris: Are you saying that you don't know anyone using machinery task, or strict/general?
Jang: Especially in machinery I think something like context does have a meaning, I wouldn't drop that because it would become more like a concept. I'd be interested to find out from large scale users of both machinery task and general task what the authors are actually running into, what their requiremets really are. Do we know that kind of thing or do we only get it from our own experience on the TC?
Kris: I'm just going to ask folks in general to think about this email and raise points on the list.

12. dita-users moderation
Don Day assigned Magliery and Essig moderator rights
Need to schedule brief telecon to go over responsibilities

13. DITA 2.0 stage three proposals

14. DITA 2.0 stage two proposals

15. DITA 2.0 stage one proposals
Initial discussion:
Redefine in bookmap
https://lists.oasis-open.org/archives/dita/201804/msg00104.html (Kimber, 30 April 2018)
Eliot: glosslist as currently defined in bookmap says that it represents a generated glossary list and that's fine but there's no defined mechanism by which a tool could know how to generate glossaries. But if we also integrate the glossref domain in the way that Eric described then it makes sense to make glossref a child of glosslist. Then it would no longer be generated and we'd need to make it clear that using it to generate a little glossary is an acceptable alternative
Kris: Is this just a tweak to existing spec language or do we need a proposal?
Eliot: It may require a proposal, I haven't thought about it in more detail than in the email
Kris: I think you're maxed out with proposals right now
Kris: Is anyone on the call interested in moving this foward?
Eric: We might as well add it to mine because it will fall in together
Eliot: glosslist does allow multiple glossdefs so I think it's just spec language; just change the content model to allow topicref or glossref
Eric: That's how I would envision it

12 noon ET close
-- Mr. Tom Magliery
Document Name: DITA TC Meeting Minutes 8 May 2018

No description provided.
Download Latest Revision
Public Download Link

Submitter: Mr. Tom Magliery
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2018-05-08 16:02:16

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