[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes, DITA TC meeting, 20 Sept 2016
=================================================
Minutes of the OASIS DITA TC
Tuesday, 20 September 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Regrets: Chris Nitchie, Deb Bissantz, Eric Sirois
Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201609/msg00014.html (Nancy Harrison, 06 September 2016)
Proposed by Kris, seconded by Dick, approved by TC
Business
========
1. Action Items
2 August 2016:
Robert: Produce initial draft of "DITA and DITA-OT" committee note
Robert; goal is to have something to check in by next week
Kris: Schedule meeting for small group working on "Upgrading" committee note (IN PROGRESS)
23 August 2016:
Joe: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN
Joe; no response yet
30 August 2016:
Eric: Review spec and suggest changes for issue raised by France Baril
Kris: Begin organizing subject scheme education for TC (IN PROGRESS)
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
Kris; holding till we start working on errata 02
Kris: Contact OASIS about status for errata 01 (COMPLETED)
Kris; see next item
2. Announcements:
New DITA TC members: None
3. Continuing item: DITA 1.3 errata
https://wiki.oasis-open.org/dita/DITA%201.3%20Errata
DITA-1.3-errata-schedule
Catalog errata that did not get updated
https://lists.oasis-open.org/archives/dita/201609/msg00006.html (Anderson, 8 September 2016)
Robert; 2 issues,
1. [minor annoying one] in 1.2, we shipped public IDs for 1.x; but we dropped them from 1.3 catalog, these need to be restored.
2. at 1.3, public IDs actually changed for a couple of modules, so if you had used those in your shell, the shipped catalog wouldn't recognize your shells, we need to restore the old IDs to the catalog
Kris; we in the TC can comment on the errata when it's out for public review. We can do this for the public IDs, but not the catalog entries, since that would constitute a substantive change. We have to wait on that for errata 02. btw, why not fix catalog entries?
Robert; it would be extremely tedious and quite a bit of work. Also, it's unlikely they're getting much use, nothing we ship actually uses them, so I consider it a lower priority as well as a bigger job.
Kris; any objections? if not, we'll fix the minor issue in 01, and hold the other for errata 02.
Update from Chet
https://lists.oasis-open.org/archives/dita/201609/msg00022.html (Ensign, 14 September 2016)
Kris; we're seeing a bit of delay in OASIS handling of errata 01, which is somewhat concerning; OASIS regulations say there will be a 2-week turnaroundm but it's not working that way for this errata.
4. Continuing item: Issue with leaningObjectMap content model
https://lists.oasis-open.org/archives/dita/201608/msg00068.html (Sirois, 17 August 2016)
https://lists.oasis-open.org/archives/dita/201608/msg00069.html (Eberlein, 17 August 2016)
[hold for Eric]
5. Continuing item: Work on committee notes
Update to "Why Three Editions"
[on hold to align with release of errata 01]
"Upgrading to a new version of DITA"
"DITA the standard versus DITA Open Toolkit"
6. New item: E-mail on dita-comment
Feedback from oXygen about 1.3 usage
https://lists.oasis-open.org/archives/dita/201609/msg00030.html (Forwarded by Eberlein, 20 September 2016)
Kris; this came from Oxygen, feedback in their survey was that 'porting plugins to Relax-NG needs to be covered in DITA TC docs rather than Oxygen docs. I think this is 2 issues, 1) porting to RNG and 2) porting to 1.3.
Eliot; if your program provides processing, it's not relevant, if it's a vocabulary plugin, it's an interesting challenge, but not really a TC issue per se.
Kris; query to vendors and consultants on the TC; do you have clients who want to port to RNG? In my work with clients, I've only seen new folks who wanted to start in RNG, not folks who wanted to port to it.
Eliot; I'm trying to get RSI to pressure XOpus to use RNG instead of XSD, but no luck. because of products that support XSD but not RNG, the motivation to move to it is pretty low.
Kris; so are there adjunct materials we or others should be providing? For example, wrt 1.3, we're working on a committee note.
Eliot; I'll have something in my book update, and it would probably be good to have a white paper, but I can't volunteer to do that.
7. Continuing item: DITA 2.0 discussion
Specification
https://lists.oasis-open.org/archives/dita/201609/msg00005.html (Eberlein, 6 September 2016)
https://lists.oasis-open.org/archives/dita/201609/msg00007.html (Anderson, 8 September 2016)
https://lists.oasis-open.org/archives/dita/201609/msg00008.html (Magliery, 8 September 2016)
https://lists.oasis-open.org/archives/dita/201609/msg00009.html (Kimber, 8 September 2016)
https://lists.oasis-open.org/archives/dita/201609/msg00010.html (Anderson, 8 September 2016)
https://lists.oasis-open.org/archives/dita/201609/msg00026.html (Eberlein, 19 September 2016)
Coverage of attributes in specification
https://lists.oasis-open.org/archives/dita/201609/msg00025.html (Leigh White, forwarded by Eberlein, 18 September 2016)
Kris; let's look at ways to re-do the written spec and artifacts. The original spec had a lot of tutorial elements; for 1.3, it's still a blend of specification-type content, best practices, processing implications, guidelines for authors, etc.
Robert; One thought I've had, rather than doing an 'architecture spec' as part of the spec, broken down into a bunch of major components, maybe we should simply have those as major components within the spec, not under 'architecture'
Kris; let's use another word instead of grammar, use 'element reference topics'
Bob; we also need @ reference topics.
Robert; I think we discussed this last time; it would be good to come up with a new way of doing that.
Kris; yes, Leigh White just recently asked for a 'quick reference' for @s as well as elements.
Robert; regardless, we'll have something very much like what we have today. but the @ defs are spread across the language reference. There's a place where you can find many @s, but not all; we should have a place you can find all @s.
Kris; Leigh suggested a list of hyperlinks to go to. you're suggesting a central place for @s, plus access from elements as well.
Robert; right now, getting to @ definitions is primarily done with links. For almost any element, most @s are accessed with links. but for any @ that's unique or uniquely defined for an element, it's defined in the element; it would be good to have a central set of definitions. For one thing, it would highlight holes in the architecture.
Kris; 2.0 would be a good time to re-formulate definitions of the @s, where we have issues.
Keith; There doesn't seem to be disagreement on these points.
Robert; I'm not sure, but we don't have something to look at, so it's hard to respond.
Kris; there's been agreement over a number of years that it's not easy to locate info about @s. We need something akin to the element quick reference we introduced in 1.2.
Bob; we don't want to get into slavish separation of elements from attributes.
Dawn; I agree, @ reffferences should be in both places, using reuse mechanisms
Kris; I also agree; usage of elements is dependent on @s, so users have to be able to get to them from different places. This is our opportunity to re-do the spec. I've looked at the element topics describing the core DITA elements, the ones expected to be used in LwD. Looking at those element topics, their content is all over the map, some content for authors, some best practices, some content related to making complicated syntax, some content for DITA practicioners, some for IAs, as well as content for implementers, Can we determine what content we need, and who the apppropriate audience is, and separate it out in a clear pattern? The spec will never be easy to read, but the better organized we make it, the better it will be. Can we determine what info we're trying to rprovide, and have clear patterns about where we put that info?
Bob; it would be nice to have a 'master pattern' for element and @ reference topics, and have some part[s] omitted for some elements/attributes.
Keith; what about talking about the user, to have an idea of what users we're aiming at for whatever we're writing?
Kris; we have to be careful, most info has to be aimed somewhat to DITA authors, but a lot of material is mostly for DITA implementers.
Bob; but every section doesn't have to be for everybody.
Kris; and some sections are used in different ways, so e.g. the audience for shortdesc is authors, other stuff is aimed at other users.
Stan; some specs are not designed to be read by human beings; but they have descriptions of various audiences and generate smaller views of the doc for different audiences, maybe we could do something like that to demonstrate DITA's capacity.
Kris; a nice vision, but not doable as the spec is now.
Keith; but mapping out those audiences would be a good idea.
Dawn; a good first step, definitely.
Keith; I'm hoping we can discuss audiences for different sections of the spec.
Kris; /that's a tricky area; the spec has been a catch-all over the years. Recently, we've been trying to move it towards what a real spec does. Do we need to rethink how we need to deliver this material?
Keith; I'm all for that.
Kris; if we have clearer written statements; who are our audiences most effectively? How do we handle gray areas where we're targetng multiple audiences?
Keith; Another thing is that we can't please everybody, but it would be useful to narrow it to 2-3 top audience types per section; some audiences will still not find what they're looking for in the spec, but they m ight find it somewhere else.
Kris; TC or Adoption TC can also produce other non-spec material in committee notes or white papers. Other thoughts?
Bob; I'm still interested in getting L&T and maybe techcontent out of the core spec.
Kris; The problem is that currently, the TC doesn't have enough core competency in L&T to maintain it; it's not such a problem for techcontent. So how to deliver L&T and techcontent for 2.0 isn't clear to me.
Bob; but there's a natural division with LwD, L&T, Taking out L&T and LwD, without taking out tech content as well, elevates techcontent to a hitgher status than LwD or L&T. There also isn't a need to update L&T or techcontent as frequently, so there's no need to tie it to the base schedule.
Kris; that was the original reason for creation of the techcomm SC; that didn't happen for 1.3 (except for great work on troubleshooting). other thoughts?
Robert; I think it would be nice to not have L&T and techcontent schedules tied to base; it would be nice to have a deliverable that's just the base.
Scott; that's what DocBook did with the DocBook publisher's spec, and it worked well for us.
Robert; if there's a specialization shipped in 2.0 as part of the core, e.g. techcontent, it has to be maintained and backwards compatible, through all of 2.x. It would be nice to not have that for techcontent.
Robert; most of us on the TC have some interest in and knowledge of techcomm, but we should still separate it, and if we do, that becomes a model for other specializations.
Kris; as chair, I've pushed to close inactive SCs. I'd also like to see a situation where anything we continue to include as an OASIS work product has to have a clear owner. I think techcomm SC should own techcontent, L&T SC should own L&T, LwD SC should be the owner of LwD (as it is now). I'd like a requirement that SC chairs be voting members of the main TC for continuity, but that isn't working out. So we need to get a new chair for L&T. Anything continuing to ship as owned by the TC - either core or profiled package - needs an active SC that's responsible for its content.
Robert; I second that, we need to have active SCs with chairs that are active voting members of TC.
Keith; would it be worthwhile to send out a tweet to that effect? I know some clients using it. ?
Robert; it couldn't hurt, but it would be better to do it more obviously thru OASIS.
Kris; it's one thing to be helping SCs get more active members, but we don't want to look outside the current OASIS DITA community for SC chairs. I'd really like it if Amber and/or Dawn would consider chairing L&T SC.
Dawn; I might be interested
Amber; it would be good to get a fresh infusion of members.
Keith; I'll be at user's conference next week; I'll talk to clients who are using L&T to see if they're interested in jopining the L&T SC.
Kris; once L&T leadership is in place, we can try to drum up more membership interested. In the meantime, would be good if everyone looked at core langref topics. Please look at the multiplicity of content, and think about how to split it out.
11:59 ET Close
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]