dita message

Subject: Groups - DITA TC Meeting Minutes 2 May 2017 uploaded

From: Nancy Harrison<nharrison@infobridge-solutions.com>
To: dita@lists.oasis-open.org
Date: Mon, 8 May 2017 00:19:33 -0700 (PDT)

Submitter's message
Action Items:
none recorded

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

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

2. Approve minutes from business meeting on 18 April 2017:
https://lists.oasis-open.org/archives/dita/201704/msg00025.html (Tom Magliery, posted 21 April 2017)
moved by Kris, 2nded by Nancy, 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 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
07 March 2017:
Robert: Update DITA 2.0 process to include link to instructions for stage 3 reviewers / reinforce idea that reviewers need to validate proposals
- Robert; this is done
21 March 2017
Kris: Post to L&T SC, TC list, and dita-users about closing L&T subcommittee if no leadership steps forward
Kris: Communicate formally with Dawn Stevens and Amber Swope about possibly closing L&T SC
Chris: Post to TC list about his thoughts for modifying bookmap design

5. Report back from CMS DITA NA conference
- Nancy; technology kitchen area was a real success.
- Scott; yeah, I spent most of Monday out there.
- Kris; how did seesions go that were put on by TC members?
- Bob; I did one on techcomm SC; some folks may be interested in joining.
- Carlos; same for LwD session; good questions, generally positive response.
- Stan; wrt session on listening sessions, maybe a little bit too much time on results, but we did have a real listening sesssion, and we really got across that we really want their help.
- Keith; I also thought it went well; we got good reasponses from crowd for what they want to see going forward. I'd echo Stan; we spent too much time on results, not enough on actual listening session. Also, the session Leigh and I did was standing room only. Also lots of folks at the 2.0 talk on Tuesday.
- Mark; a lot more younger people were at the conference than usual.
- Chris; a lot of interest in LwD and lightweight everything else, Github, Eliot's talk on D4ST.
- Kris; that might be hard on vendors...
- Mark; it's good for the community, though.
- Keith, and people get into DITA with small solutions, then move to larger-scale ones and come to us and other vendors.
- Chris; as a vendor on the delivery end, we got a lot of interest from folks. People are getting far enough along in their maturity model that they're thinking more about delivery.
- Scott; there were comments about wanting listening sessions in the upper midwest. Many folks are not thrilled about Yahoo group, want to start a slack channel to improve it.
- Kris; it will be interesting to see what comes up. dita-users is solid and mature.
- Robert; I don't know how a slack channel would work, the content is very ephemeral if you don't pay for it.
- Dawn; we got lots of good responses from varied people; attendance was up by 20% from previous year; many brand new folks. It was a good event in terms of who we reached.
- Robert; despite the buzz on LwD, there was continued interest in full DITA. Ideas from user community, e.g. turning chapter/part into a domain. We have to be careful of what we say, to keep people from misunderstands creating fear.
- Kris; I wish we could do a better job of communicating to non-technical people the concepts underlying shells and things.
- Carlos; I ran into someone who heard 2.0 might be backwards incompatible and thought it wouldn't support her 1.3 implementation.
- Kris; we've got to do better than that.
- Don; any reactions to beta version of dita.xml.org?
- Keith; it came up, but there were no chances to show it off.

6. Continuing item: Formal work on DITA 2.0

a. DITA 2.0 Proposal: Add to
https://lists.oasis-open.org/archives/dita/201703/msg00030.html (Chris Nitchie, 30 March 2017)
https://lists.oasis-open.org/archives/dita/201703/msg00030.html (Anderson, 30 March 2017)
https://lists.oasis-open.org/archives/dita/201703/msg00032.html (Chris Nitchie, 30 March 2017)
- Chris; it's fairly straightforward; allow a title in a map; the reason is in the way that bookmap manages alternate titles; they're all specs of 'ph'. This would break that out and allow maps of any type to have titles separate from the main title, and add a generic 'title-slt' to 'title-alts' that could be specialized.
- Robert; it's a great idea, but how do we reconcile it with what's already there? To get an ideal solution might to be remove our current specialized titles to replace with title-alt, but that would be backwards-incompatible.
- Chris; we could put the new element in topicmeta. if we put title-alts inside topicmeta, that would work, and it just leaves the existing cruft...
- Kris; how many organizations actually use searchtitle and navtitle?
- Robert; people use it, and tools auto-insert it.
- Nancy; yeah, my clients use it.
- Kris; What shall we do?
- Robert; given that it's at stage 1, we still need to handle all the details.
Chris; and that comes in phase 2.
- Robert; since the email is the stage 1 proposal. we just need a vote to move it to stage 2.
- Chris; I so move
- Robert; I second.
[proposal is moved to stage 2 with Chris as owner]

b. DITA 2.0: Make all profiling attributes specializations of @props
https://lists.oasis-open.org/archives/dita/201703/msg00033.html (Chris Nitchie, 30 March 2017)
- Chris; the idea is to change the definition of all the alternates to @props (audience, product, etc) to become specializations of props, rather than their own top-level thing.
- Kris; will you put them in their own domain?
- Chris; every @ needs its own domain, so we'd need 4 domains, in a world where we don't have the domains @, I don't know how to answer that question.
- Bob; I'd like to have them in separate domains, so people could configure shells with just what they need.
- Robert; I tend to agree, even though it would be more convenient as one domain. I understand that current rules require one per domain, even it that's not reasonable.
- Bob; implementation will have to wait till we hash out our stance on domains...
- Robert; yeah.
- Kris; other than archictectural purity, what benefits do you see from this change?
- Chris; it allows you to develop a shell without a new constraint.
- Robert; and processors can now have one rule for profiling instead of 5.
- Carlos; in LwD we just have props; this would go with that.
- Robert; there are a whole bunch of rules that appply to props and every spec of it, except those 4; this would simplify that.
- Chris; and current state adds complications for processors.
- Don; this is one of the 'why didn't we do this a long time ago?'
- Robert; because it's backwards incompatible...
- Kris; do we want to move this to stage 2 also?
- Robert; just a note; Chris already has 2 proposals; I'd be willing to take on this one.
- Chris; that's OK with me, and the next one is more important to me
- Robert; I move we move this to stage 2.
- Chris; I second
[approved by TC, moved to stage 2]

c. DITA 2.0: loosen attribute specialization rules
https://lists.oasis-open.org/archives/dita/201703/msg00035.html (Chris Nitchie, 30 March 2017)
- Chris; If I create a new element, I should be able to create a new @ for just that element, rather than have it be globally applicable.
- Robert; I agree; the only reason we have this is that the laser-like focus was on modularity. Practically, this is preferable.
- Chris; i propose that at 2.0 we ship new DTDs that are perfect, and later a set of DTDs that have new functionality but are backwards-compatible. We can introduce domains that make shells that make those features backwards-compatible.
- Kris; any questions about this proposal? We'll certainly need to add language to the spec to explain this.
- Robert; I'm not sure how much we need to talk about it; it will depend on rules for writing RNGs; we can start with just removing rules that don't need to be there.
- Chris; if I develop a base specialization for one element, and Robert develops a different specialization with the same name, you end up with duplicate tokens, but that's not so harmful.
- Robert; but that's not so different from what we have today; this is a minor annoyance.
- Chris; I move this proposal to phase 2
- Robert; I second
[moved to stage 2; chris is not alowed any more until these are done]

7. Review of stage one (in progress) cards
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
- Redesign how grammar files are structured for delivery
- Mandate a processing order
- Robert; this has been a dream of mine since DITA 1.0. It would be great if we had a processing order for evaluating features, both for users and implementors. There are cases where different orders give really different results, and that's a pain. But this won't be easy..
- Eliot; my analysis is that for some things, there's only one right way to do it.
- Robert; if so, we should tell people so they don't have to figure it out themselves.
- Eliot, in the past, if you did conref resolution before filtering, you'd get diff results than if you did it the other way.
- Chris; also an issue with branch filtering and keyscopes, relative to conrefs.
- Eliot, you need to resolve all conrefs, then do anything else. Also, being able to do filtering-aware processing, if you know that certain keys will eventually be filtered out, you can avoid doing a branch filtering expansion if that branch will end up getting filtered out.
- Robert; it's all very complicated. in DITA-OT, the default is to do the filtering first, but I'm willing to entertain the idea that that will not be the correct answer. In my experience, conref and filtering is the sticky one. At IBM we do filtering first for historical reasons.
- Eliot; but that becomes too problematic in the face of DITA 1.3. I did my capture of my analysis of the processing and posted it to DITA-OT dev list; I can post it to this list also.
- Kris; questions? And is there a reason why processing order wasn't specified initially?
- Eliot; because IBM had a compelling need to do filtering first, even though it was wrong.
- Robert; not sure of that, but I wasn't around then. regardless,
- Kris; if we do this, what would be the effects on existing implementations that do it differenctly?
- Chris; it depends on strength of our compliance statement.
- Robert; either they'll have to change, or they won't conform unless our conformance statement is weak enough to allow it, or they could be listed as limitations of the product.
- Chris; my sense is that re-ordering things wouldn't be free, but it wouldn't be a wrecking ball.
- Eliot; my sense is that processes that really don't work, won't give you the correct answer for 1.3 either.
- Kris; would it allow us to have a stronger conformance statement? What shall we do with this proposal? We can't move it to stage 2 t6ill it has an owner.
- Robert; I assumed for a long time that I would have to own this; if it moves into stage 2, then it will block me from taking any others till it's fixed.
- Don; do we want to change the rules? for consistency vs new features?
- Robert; I disagree; I can add my name to it is but keep it at stage one, knowing I'll have to get to it eventually.
- Kris; let's do that. but open an issue for it.

Other:
Bob; I put a stage 2 draft up on Kavi for splitting base and techcomm.
Kris; please send email to the list about it.

12 noon ET close

-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 2 May 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-05-08 00:18:57