Zoe, I saw that and added you to the roster. Nancy, can you modify the minutes to add Zoe to the attendance? Many thanks.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com
Skype: kriseberlein; voice: +1 (919) 622-1501
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
On Behalf Of Zoe Lawson
Sent: Friday, August 19, 2022 5:56 PM
To: Nancy Harrison <nharrison@infobridge-solutions.com>; dita@lists.oasis-open.org
Subject: Re: [dita] Groups - DITA TC Meeting Minutes 16 August 2022 uploaded
FYI, I was there. I dialed in somewhere in the middle of #8. I announced myself in the chat but didn’t have anything to say.
Submitter's message
ActionItems: none
=================================================
Minutes of the OASIS DITA TC
Tuesday, 16 August 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
===========
Robert Anderson, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Eliot Kimber, Eric Sirois, Dawn Stevens, Frank Wegmann, Melanie Petersman, Stacey Meggs, Jim Tivy, Todd Thorne
Business
========
1. Roll call
Regrets: Scott Hudson, Zoe Lawson
2. Approve minutes from previous business meeting:
09 August 2022
https://lists.oasis-open.org/archives/dita/202208/msg00019.html (Dana Aubin, 09 August 2022)
moved by Kris, 2nd by Dawn, approved by TC
3. Announcements: none
4. Action items
[updates only; complete list in agenda]
09 August 2022
Robert: Handle bug fix in hazard statement grammar files
- Kris; any progress on this?
- Robert; no, I'll get on that today.
5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; Eliot, I'll start pestering you abaout cleanup fixes, but not till next week.
6. DITA 2.0 stage two proposals
Initial discussion
Issue #670 "Add new impose-role attribute"
https://lists.oasis-open.org/archives/dita/202208/msg00021.html (Anderson, 15 August 2022)
- Robert; we had a discussion a few weeks back; the issue is to formalize what's been a wishy-washy statement in spec, where a reference within a bookmap that refs another map needs to treat it as a chapter, but we didn't provide a way to actually do that;
this proposal fixes that, with an @impose-role that allows users to specify what they want..
- Kris; any questions or comments? Gershon had posted one correction, so you'll need to make that.
- Robert; right
[no other questions or comments; TC will vote next week]
7. DITA 2.0 stage three proposals
Vote
#15 Loosen speclialization rules/add expansion moduules
https://lists.oasis-open.org/archives/dita/202208/msg00008.html (Eberlein, 07 August 2022)
- moved by Kris, Gershon 2nd
Voting results:
yes votes 10 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Eliot Kimber, Eric Sirois, Dawn Stevens, Frank Wegmann)
no votes 0
8. DTD examples in DITA 2.0 spec if RNG is normative
https://lists.oasis-open.org/archives/dita/202208/msg00024.html (Joseph, 16 August 2022)
https://lists.oasis-open.org/archives/dita/202208/msg00025.html (Eberlein, 16 August 2022)
- Gershon; while doing review H, I noticed it's annoying, when reading spec, to go between RNG and DTD examples. I don't think we need to address multiple grammar formats; it's easier to read and maintain if we only use RNG implementation. We may need a CN
with the DTD versions to calm some users down. At precisionContent, we generally deliver a single XSD file that implements all of the RNG. so tools don't need the complexity of the architecture. Wouldn't 2.0 be easier to parse if we used just one grammar?
Some of our clients don't want multiple DTDs anyway.
- Kris; the point is that DITA TC explicitly supports both DTD and RNG grammar files; normative means that if they differ, RNG wins, not that DTDs aren't fully supported.
- Eliot; I'm sympathetic to Gershon, but there's a large body of DTD specializations, for which a monolithic DTD wouldn't be appropriate. I don't think a monolithic DTD is sufficient.
- Robert; I've felt for a while that the spec would be better off if we removed all the grammar patterns; the spec should care about the content of files, not how you do them. In my perfect world, they would both be moved out and everyone would use RNG. But
that's not the world we're in today. Gershon said that 'most tools only support XSD'; but I've mostly found tools that support DTDs.
- Gershon; the DocBook spec did change from DTD to RNG. I definitiely support moving both out.
- Nancy; I'd support this only if a CN containing both sets were always published, simultaneously with the spec.
- Kris; Robert and I said the patterns should be in the coding practices sections; so either everything goes to a CN, or it stays in the spec in one place. I'm curious about the tooling you see, Gershon, that is XSD based; I've only seen XOpus
- Eric; another company out of Vancouver uses XSD, and SDL uses some XSD under the covers.
- Gershon; most of our clients use XSD. if we take them all out, that wuold make the spec easier to read, and we don't have to figure out how they differ. If they're going to be together, then put the RNG first; now it's second.
- Kris; one thing OASIS sugested was to organize our content alphabetically, so we've done that. That's why DTD comes before RNG.
- Gershon; I'd propose an exception to alphabetical for this case.
- Kris; I think these are good and valid points for us to consider. But I'd have strong objection to making these changes for 2.0; they're major changes and we have major resource constraints around editorial work. I'm much more concerned, for 2.0, about having
a very good chapter in spec about map processing.
- Robert; I hadn't given up on moving all of it out for 2.0, but we're so bogged down.
- Kris; another thing to consider is to move all that content to non-normative appendices; we would have to be really careful; we've dumped a lot of content into non-normative appendixes. If we did this, we'd have to prune other stuff.
- Eliot; is there any normative language in the coding practices chapter?
- Robert; I don't think so.
- Kris; easy enough to check, I'm looking now.
- Eliot; I could certainly support moving that material to non-normative appendices.
- Kris; I don't have normative statements in that chapter; all in the MUST or SHOULD; I'd suggest we not make a decision at this point, since it's extra work. We could move it to an appendix, or we could re-architect our appenices. Most folks seem to want it
to be moved out of the general spec. We should hold on that decision till we can do a review of appendices and see how much work it would be.
- Gershon; we need to do it wisely; we can't just hack it to pieces. I can help a little. I could get some other folks from PC to look at it. Maybe they can identify things...
- Kris; we would need to start doing a review of those topics in appendix C; what we think is critical, what to remove, what to modify or re-architect. and we should do it as a precursor to even reviewing this content. We have some critical content in there,
but there are other things we need to look at more carefully, e.g. processing and interoperability considerations. We can put it as an item for next week's call, to talk about:
is it important>? should it be removed? does it need more work? I don't think we've done updates to the sections on 'what are domains and constraints' and 'how are they used in starter grammar files?' Any objections? thoughts? comments/
[none]
9. Schedule for upcoming DITA 2.0 spec reviews
https://lists.oasis-open.org/archives/dita/202208/msg00012.html (Eberlein, 08 August 2022)
- Kris; we'd put off generalization because we thought so much content needed to be modified; it's scheduled for 2 weeks since it's a decent chunk of content. Any thoughts? comments? questions?
[none]
- Kris; I'll get the next review out to everyone. in ContentFusion, revision @s are a little distracting; I might remove them from DITA source to make it easier.
10. Options for channeling funding to the TC
https://lists.oasis-open.org/archives/dita/202208/msg00007.html (Eberlein, 03 August 2022)
Update from Eberlein
https://lists.oasis-open.org/archives/dita/202208/msg00023.html (Eberlein, 16 August 2022)
- Kris; we've reached the point in our maturity model where we are experiencing problems with getting enough spec editors. It's almost a full time job, and so we're looking at how we can enable funding to support spec editing and/or development work. I suggestd
we create a DITA foundation, but it's work to set one up and work for the board and for accounting. I talked to OASIS, they suggested working with Open Collective. If we worked with OC, OC would get 10% of money collected, and OASIS would take 25%, so it would
probably not be attractive to potential donors. Maybe we should have our own foundation...
- Eliot; it's encouraging to see that there are actual ways to get funding.
- Stan; I'd be willing to help.
- Kris; great.
- Nancy; I think 15% rather than 25% might be ok, but 35% total is just too high; we should try to get OASIS to understand that keeping this TC going is in their interest, and if we have to stop work, it will affect them as well as us.
- Kris; good point.
11. Volunteer tasks
https://wiki.oasis-open.org/dita/volunteerTasks
- Nancy; I looked at lists of agendas/minutes, and it looked like there were already links to minutes for them.
- Kris; no, those are just placeholders.
- Nancy; I'll look at them again and work on it this week.
- Kris; Eliot; what about the proposal for cleanup chapter?
- Eliot; will work on it next week.
- Kris; of any items you've voluteered for, this has the highest priority.
- Kris; dawn, how about the draft of changes from 1.3 to 2.0?
- Dawn; we talked about it last week
- Eliot; I just sent you an email; i've been trying to capture those changes for the CN.
- Kris; and I have some data from last year. btw, when we talk of moving stuff to appendices, we're not moving examples from arch spec.
- Kris; wrt the Github repo work, Robert, we should talk about this.
12 noon ET close
-- Ms. Nancy Harrison
|