dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 15 September 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Tue, 13 Oct 2015 02:21:58 -0700 (PDT)
Submitter's message
=================================================
Minutes of the OASIS DITA TC
Tuesday, 15 September 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: Tom Magliery
Standing Business
=================
https://lists.oasis-open.org/archives/dita/201509/msg00059.html (Harrison, 8 August 2015)
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/56476/minutes20150908.txt (updated version)
Proposed by Kris, seconded by Don, approved by TC
Subcommittee Reports
none
Announcements
None
Business
========
1. Action items
25 August 2015:
Nancy: Convene working group for "Why Three Editions of DITA 1.3" (in progress)
8 September 2015:
Tom: Create DITA 1.3 errata page (Completed)
2. Comment from Chet Ensign
https://lists.oasis-open.org/archives/dita/201509/msg00064.html (Chet Ensign, 14 September 2015)
- Kris; I'm not sure, in response to the minutes, what he was trying to say.
- Don; he's saying that even if the CS is not approved, it will no longer change.
- Robert; just from talking to Chet about conformance statement, his comment is also related to IPR; once you've reached the status of a CS, you have the IPR statement. That states that you can't be sued for implementing this; vendors can implement without fear.
- Kris; yes, that was coming through, but from an implementer's POV, things could still change. There's a little bit of discrepancy, because theoretically, we could still pull back the spec and make changes.
- Eliot; but the implication is that it wouldn't have gotten this far if we weren't pretty sure this was correct.
- Robert; And as he mentions, some TCs don't even bother to go past CS to approval; I don't understand that, but it is the case. And our spec references several other documents that are not all standards.
Eliot; W3C doesn't produce "standards", they produce "recommendations".
- Don; Chet was talking to us, but also through us to potential adopters; we should ask him if he intended for us to convery this outwards.
- Robert; if he meant that, he would have said so.
- Kris; but we have a discrepancy. Yes, this may be a final OASIS specification, but we could change it.
- Don; one extra question raised by our graphic might be: 'at what point on the graphic is it when I should be able to adopt this and start using DITA 1.3?" Maybe that's what he's telling us.
- Nancy; DITA 1.2 was much less organized than 1.3 has been and this question never came up.
- Kris; the graphic doesn't indicate that you can start using 1.3 now.
- Don; we're at the stage where the grammar is well-cooked, and you can start using it. Is there anything we could change that would be backwards-incompatible?
- Kris; I wish Tom were on call, since it was his graphic. We can keep this on agenda till next week, but can start telling
- Don; just fyi the Best Practices conference is next week, and some of us will be there. How to make sure those of us who will be there are also on the TC call?
[Kris; Don, Joann, Scott, Keith will be there, but Joann and Scott will be pretty busy, since it's their conference. Scott went over conference details wrt whether attendees could take part in the call...]
- Kris; keep this item on agenda for next week.
3. Calendar for critical dates to enable DITA 1.3 to be released in 2015
Schedule: July - December 2015
Kris; slip of one day due to chet's being on vaca, otherwise no change
4. New item: Relatively benign bug in troubleshooting.dtd
https://lists.oasis-open.org/archives/dita/201509/msg00062.html (Bob Thomas, 12 September 2015)
- Bob; inclusion is strictTaskbodyConstraint is a mistake; there's no utility to it being there, but it also doesn't cause a problem because it's redundant.
- Kris; What shall we do about it?
- Bob; we ought to just pull it out; the only impact is that the (topic task strictTaskbody-c) domain shows up in troubleshooting topic; it shouldn't be there a from purist point of view, but it has no impact...
- Robert; the problem is that troubleshooting reuses the steps element, so it references the task module; if you conref, you can get the steps element, but you have to verify that if you're using task element they're equally constrained.
- Michael; but with strong/weak constraints, it shouldn't be a problem; having an extra constraint makes it easier to conref stuff into it, but harder to conref stuff out of it.
- Bob; it's probably OK to just leave it as it is; most of time, you're conrefing out of a task, not into it.
- Michael; I agree
- Robert; I suspect no one else will notice that it's there; I don't think anyone will try strong constraints; we should leave it as is, as a quirk.
- Eliot; in any case, the shells are just an artifact; they have no normative value.
- Kris; the question is; do we want to document this as a quirk, or consider for fixing, or decide it's just working and leave it be?
- Robert; as to documenting it, where would we do it, so that someone using it would find it?
- Don; maybe we could just deprecate it in a future release in our notes?
- Robert; No, we're not doing that.
- Kris; it's working as designed.
- Robert; it's a quirk of the complex domain rules; I hope we can simplify those, but until we do, this is working as designed.
- Bob; I'm happy to retract my objection from the email.
[TC agreed this doesn't need to be brought up further.]
5. New item: Request for Feedback: DITA Adoption SWOT "Weaknesses"
https://lists.oasis-open.org/archives/dita/201509/msg00017.html (Doherty, 4 September 2015)
https://lists.oasis-open.org/archives/dita/201509/msg00053.html (Eberlein, 9 September 2015)
https://lists.oasis-open.org/archives/dita/201509/msg00068.html (Doherty, 14 September 2015)
- Kris; Stan isn't on this week's call, but earlier in the month asked for feedback on the Adoption TC's 'SWOT' list; I didn't get it on the agenda for last week, but we should discuss it.
- Robert; I sent mail on it, suggesting one item that could be listed as weakness, and noting a bunch on the list that are outdated or don't belong. I'm not sure what is the purpose of the list, Currently it's just a list of weaknesses, many invalid. I'm not sure what else to say about the goal of list, but would encourage everyone to go thru it. Many items are outdated. e.g. 'all the map editors suck'
- Don; I agree
- Robert; I didn't understand why the DITA-OT is listed as 8 different weaknesses; it's an old list; none of the items have any explanations, and many don't make sense on their own.
- Kris; it would be just as possible to describe DITA-OT as a real strength for the community, rather than a weakness...
- Don; DITA-OT is just one innterpretation; it enabled vendors to get tools out faster.
- Robert; some criticisms of it were unwarranted; if we had pros and cons of various vendor, we could list the Toolkit among them, but this just list toolkit weaknesses without context.
- Don; the current tools are much stronger than when most of these comments were written; vendor ecosystem is much richer; we're in a far different, far better place.
- Don; Robert, you just gave a good description of how DITA-OT needs to be considered in any SWOT, as just one of many implementations.
- Michael; I'm not sure we should conflate DITA and DITA-OT; people are already confused about how to relate them; we shouldn't ever mention DITA-OT separate from other implementations
- Don; that would be a SWOT of the tool itself, not of DITA; it's actually a strength of DITA is that it has so many vendors.
- Robert; I don't want to imply that another tool is incorrect because DITA-OT is correct; it's not relevant to a large class of DITA users. Some other items also don't belong. I don't want my email to be overlooked, but hope others will go thru the SWOT and clean up other items.
- Kris; thoughts/comments?
- Chris; I agree with everything Robert said.
- Keith; ditto
- Kris; this SWOT list came to the TC with a request for feedback, but it's a brain dump of 2008.
- Robert; and no one ever reviewed it at that time.
- Keith; we could just say 'obsolete' for those items.
- Don; we can say 'no longer applicable' and go on.
- Kris; one issue is that there is old unusable stuff out there, and people find it; all we can do is optimize our good sites.
- Robert; one worry I have is our coming across as not liking the idea of a SWOT; I know this is out of date, and it was presented as such.
- Keith; part of the goal was to get consensus on what is obsolete; we'd like to get all views on this; as part of moving good content to a dita.xml.org, we'd like to fix this up now.
- Don; TC, please review
- Kris; deadline towards end of this week
6. New item: Is the "Scoped keys" feature article ready for the DITA TC to review?
https://lists.oasis-open.org/archives/dita/201509/msg00069.html (Eberlein, 15 September 2015)
https://lists.oasis-open.org/archives/dita/201509/msg00070.html (Hackos, 15 September 2015)
https://lists.oasis-open.org/archives/dita/201509/msg00071.html (Bob Thomas, 15 September 2015)
- Kris; this is another question of how TC and Adoption TC interact; I sent mail asking if this feature article was ready for review; we had been told earlier that it wasn't ready for review. Joann also said it had been reviewed (maybe she was confused between it and A-Z paper?)
- Bob; I think there are some issues with coordination between both TCs; there's definitely value in having TC review papers put out by Adoption TC; I'd like to propose a change to Adoption TC policy to include TC in request for review.
- Michael; spot on with that; this is a relationship we need to have work, and it isn't right now.
[remark made wrt reviews; rather than having/missing a 2-stage review, might be better to include TC interested reviewers as part of Adoption TC process; so, how do we make the formal request?]
- Kris; I think that would be a return to what Adoption TC did with 1.2. I tried to continue that with 1.3, to some extent, by monitoring Adoption TC.
- Keith; I've heard from Leigh that she got reviews from various TC members; so it might have seemed that to her that it had been reviewed by TC.
- Michael; so we need to get rid of 2-stage process; it can miss critical people if only joint TC members see things.
- Keith; the current system leads to confusion and miscommunication.
- Bob; I also will propose that for white papers, Adoption TC will go thru a process where we identify essential reviewers. In addition to an announcement to the TC, that will help with quality of review.
- Kris; awesome, for folks outside OASIS, people don't see any difference between the 2 DITA-related TCs, and I know how much we rely on everybody looking at the spec as much as possible. In 1.3, things got much more complicated. we went to a lot of effort to regularize terminology and language. I'd like to make sure both TCs are also uing same terminology.
- Don; I think Bob made an excellent suggestion; please take that back to the Adoption TC.
- Bob; I'll convey it as the wishes of the TC.
- Kris; any objections to proposal?
- Bob; [to clarify] I'm proposing that the Adoption TC will formally notify TC when articles or white papers go for review.
- Kris; and my response when they notify us will be to put an item on agenda and ask for volunteers to review it.
[no objections, approved by TC]
- Bob; I will reply to the thread with a note that will talk about modifying internal process, so both TC and Adoption TC will get it.
- Kris; Bob, you're the right person to do this, as official liaison between the 2 TCs.
7. Continuing item: Discussion re TAB comments on CSPRD 01
https://lists.oasis-open.org/archives/dita/201508/msg00074.html (Eberlein, 8 August 2015)
Hyperlinks for all element and attribute mentions: https://issues.oasis-open.org/browse/TAB-1276
Alphabetize lists: https://issues.oasis-open.org/browse/TAB-1273
- Kris; the comment asks that all element/@ lists be alphabetized; this is not for 1.3, but for the future. We tried to do some of this for 1.3, but much is not.
- Bob; I agree, unless there's a compelling reason not to.
- Michael; is there an example, of where there's there a compelling reason?
- Robert; this is a case where 1.0 groupings were structural where things were structural, but within the body element, things were alphabetized; there never was a clear policy. no consistency.
- Kris; what is the story we're trying to communicate in the langref?
- Robert; I don't even know if all groups are relevant - i.e., how many topic groupings came from 1.0 - without stepping back to reorganize it.
- Don; or should it be represented by navigation?
- Robert; in 1.0, an attempt was made to make order logical; in 1.1 and 1.2, stuff was just added willy-nilly. I think most should be alphabetized, but maybe not all?
[Stan volunteered to help work on this, though not lead it]
12 noon ET Close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]