See changes below
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+1 919 682-2290; kriseberlein (skype)
On 12/13/2016 1:40 AM, Nancy Harrison
Not a draft spec -- a draft committee note. Not mine either :)
1. Nancy will make links from Help SC main page to work products
2. All TC members take a look at Adoption TC white paper wiki page
and think about what you can contribute
3. All TC members look at Kris's LwD draft spec and comment on it
Minutes of the OASIS DITA TC
Tuesday, 6 December 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
1. Roll call
Regrets: Deb Bissantz, Joe Storbeck, Maria Essig
2. Approve minutes from previous business meeting:
(Nancy Harrison, 29 November 2016)
[need to be amended to correct abbr IIDR -> iiRDS]
moved by Kris, seconded by Don, approved by TC (as per amendment
New DITA TC members: None
4. Action items
2 August 2016:
Kris: Schedule meeting for small group working on "Upgrading"
committee note (IN PROGRESS)
Kris; on hold; no time or bandwidth
23 August 2016:
Joe / Kris: Get TC instance of DITAweb updated with 1.3 DTDs;
restore sync with SVN (IN PROGRESS)
30 August 2016:
Kris: Begin organizing subject scheme education for TC (IN
Kris; on hold; no time or bandwidth
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
Kris; will do this
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
Tom; no progress
18 October 2016:
Eliot: Restore DITA 1.x identifiers to catalog files (Moved to
25 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
Kris to talk to OASIS about closing Help SC.
Kris; kind of on hold;
Stan to add links from main TC page to Help SC work products.
Stan; Nancy will do this link
Nancy; I'll do it
Kris; actually has to be from Help SC page, not from the main TC
Stan: Archiving Help Subcommittee stuff
5. Report from DITA Adoption TC (Bob Thomas)
Bob; I sent out a link for all white papers planned or in
progress; is anyone able to write or contribute to one? Right now,
white papers and dita.xml.org are main foci of the Adoption TC.
Waiting for Mekon support for dita.xml.org.
Kris; everyone please take a look at the wiki page and look at
white paper list.
Bob; Stan has done that page and is driving that work.
Keith; Bob captured things on dita.xml.org. we are beginning to
add content to the site for testing purposes.
Bob; at next Adoption TC meeting, we'll have an election for a new
TC chair (to replace Joann). Right now the only candidate is
6. Continuing item: DITA 1.3 Errata 01
Announcement of public review, 6-20 October 2016
Comment resolution log for public review
Link to new package:
Kris; this is still not published; OASIS had issues with our
package. I heard about it when I was in Germany; forwarded mail to
Bob and Robert today.
Bob; I didn't reply immediately, but I think we'll be able to do
Kris; be careful; we could also go back to toolkit structure to
what we did originally for 1.3.
Kris and Bob will touch base this afternoon, whether it's best to
just do a hack or ...
7. Continuing item: Work on committee notes
Update to "Why Three Editions" (on hold to align with release of
"Upgrading to a new version of DITA"
"DITA and the DITA Open Toolkit"
Robert; no updates, need to get back to this
"Lightweight DITA: An introduction"
Need for people to participate in a call the week of 12-16
Working draft 01
Kris; posted a working draft; please look at it. We need to have a
formal written artifact from TC out, in order to provide a jump
start on the spec. It's very much a working draft, some topics are
just placeholders. We need to begin discusing what needs to be
here wrt design, compatibility, conformance... volunteers?
[Nancy, Keith, Stan, Robert, Eliot volunteered]
Kris; we need more volunteers from people with real experience
implementing DITA algorithms
Kris; give me 90 time slots when you could do a call next week.
AI; everyone look at draft and see what's missing. don't want
people implementing it based on incomplete work.
8. Continuing item: "The DITA iceberg" presentation at DITA Europe
Link to PDF
(Eberlein, 16 November 2016)
(Magliery, 16 November 2016)
(Priestley, 16 November 2016)
(Eberlein, 17 November 2016)
(Anderson, 17 November 2016)
(Magliery, 17 November 2016)
(Eberlein, 18 November 2016)
(Rob Hanna, 17 November 2016)
(Bob Thomas, 17 November 2016)
(Don Day, 17 November 2016)
(Eberlein, 18 November 2016)
(Eberlein, 18 November 2016)
Nancy; what did you hear from Leigh's audience at the conference?
Kris; it generated most the discussion among the presentations,
but I don't have a really good sense of what the tenor of audience
reation was. Yes, people are interested in LwD, and yes,
constraints are too difficult to use. but there was no real sense
that people agreed that most of DITA is too complex for most
Chris; it's amazintg how many users are afraid of specialization.
There's certainly concern about the total number of elements in
DITA, but the pain of specialization doesn't really enter into
Kris; for a small offering group, specialization and use of
constraints are just not a useful use of limited resources,
especially if working in a file system.
Tom; when we talk about these features not being wanted in DITA,
it's really folks asking for a flat DTD that has just the limited
list of elements that they themselves want, and that's not
feasible; there's a limit to what you can cut out and call it
something as valuable as DITA.
Bob; I'm not sure about that; when I looked at DITA at first, I
saw it as having too many elements and a breadth of usage that's
just not useful for most authors.
Tom; so for a vendor, it makes sense to hide stuff that isn't
useful to authors
Bob; that also relates to our next agenda item
Tom; there are things it doesn't make sense to make available to
authors, but removing stuff from the spec doesnt make sense to me
Kris; questions; do we want to distribute multiple sets of starter
shells? or go to using modular RNG fies for design, but generating
monolithic shells for authoring?
Eliot; don't see how creating monolithic shells makes creating
Robert had the idea of no longer editing modules in DTD (or XSD).
Chris; it's also a marketing problem. if you're modifying a DTD.
nowhere in the tool chain is there a tool that is for modifying
DTD/RNG. so it's not clear that specialization is part of the DITA
Tom; that would require attention from all vendors that produce
tools; right now they all bundle the tools with their product;
right now, most of the tools provide their own DTDs, and users use
the DTDs shipped with the tools.
Chris; I don't have a solution, but its part of the problem.
Jaan; I don't think there's an incentive for vendors to produce
tools to change modules. and vendors' tools all work with DTDs not
RNG. It would be good if the TC would make the tool to change the
RNGs to DTDs. People in the field are the only ones who know what
they need in their DTDs. and it shouldn't be vendor tools; should
be a 'neutral' tool.
Kris; it would be nice if there was a plugin that took RNG and
turned it into DTD, that's what we need. if it also needed a GUI,
that would be a lot of work. It's not always easy in different
tools to add support for different DTDs and swap them out; it's
easy in Oxygen and XMetal, but not at all in Frame. and many
CCMS's hack the DTDs to add their own proprietary @s.
Jaan, but if tools to generate constrained DTDs from RNG are
around, there will be pressure on vendors to work from RNG and
support use of user's specialized DTDs
Eliot, but the TC and OASIS aren't constituted to do that work; it
has to be done by volunteers outside of the TC.
Jaan, it would be better if the Adoption TC, rather than writing
white papers, was able to produce such tools.
Eliot; OASIS isn't set up to produce tools, it's just not within
its purview or mission; it's a standards org., not a tools
Stan; at our listening sessions, participants saw a hole between
OASIS, vendors, and users; there's no viable way to 'contribute'
such tools; there's no org. set up to be the recipient and holder
of such tools.
Kris; and what work TCs produce is totally dependent on who is in
them and who wants to create what. A TC can't work like a company.
Jann; then the 2nd choice would be for me to rejoin adoption TC
and do papers on how to make these tools and shout at the vendors
to make them work.
Kris; go for it...
Kris; we do have more ability than we did, now that we have open
source repositories that can contain work done by non-OASIS TC
members, but it's a question of resources.
Eliot; it's still a very much volunteer effort; over the last 2-3
years, a number of folks have investigated what it would mean to
have a non-profit org. to do this; we're too small a community for
Apache to be interested, and there's nothing else.
Kris; this is work that would need to be funded, and there are
limits to what we can do with a volunteer-led organization. In an
ideal world, we'd have a foundation or non-profit, or even paid
editors to edit the spec.
Mark; who pays editors?
Kris; some of the graphical specs have paid editors.
[discussion of paid/free/non-free standards and paying for
Dick; are we sure that the issue is tooling vs. people's
conceptual understanding of doing constraints and specialization?
Kris; that's a very good point; even if the tools were there,
people don't understand shells and configuration; it's a 2-part
problem. There's never been real education for the larger
community around configuration and specialization.
Mark; is DITA unique in this situation, or has someone else
already solved this problem?
Kris; DITA's specialization architecture is unique.
Eliot; are we talking about specialization or standarization?
Mark; I'm talking about standards.
Eliot; I don't know of any other specs like the DITA spec.
Mark; with the XML standard, it was James Clark (who is both a
genius and independently wealthy) who did all the tooling and
Eliot; in the DITA community, we were lucky to have Robert and
Jarno doing so much work on this.
Robert; large donations of time by Kris as well.
9. Tightening loose content models to facilitate authoring
(Thomas, 02 December 2016)
Bob; my sense is that our content models are too loose for
authoring; I want to remove mixed content and nesting blocks. The
idea of reducing author choices has been a point of structured
markup for some time; it makes it easier to train authors; it's
also lot easier to make choices if there are fewer; and semantics
of markup not as clouded.
Eliot; content models have to be too loose in order to support
Kris; as OASIS we ship one set of shells; they have to support
everything that people want, and they also have to be backwards
Bob; I had to identify 21 constraints for task to identify
'problem' in troubleshooting domain.
Kris; I agree with Bob; for one company with really restricted
content models, I had to create 81 constraint modules.
Eliot; there has to be a better way to do it.
Mark; in LwD, we've removed mixed content.
Bob; I don't consider this to be about where specialization will
come from, just restricting authors and what's best for them.
Robert; the problem is that they're so tied together, even though
simpler authoring can be better. As far as constraint modules go;
whether you do 80 constraint modules or one, it's horribly
complex; you have to change the content model of many elements.
Eliot; but you should be able to just restrict the base parameter
Robert, but if you have a sequence, you have to change every one.
Kris; it may be wrong, but if you're followng the rules of the
spec, you can't do that.
Eliot; for base elements, you can't do that; there's no way we
could compose the DTD that could make that work.
Kris; but if we moved to RNG...
Robert; it comes from DTD usage, plus our usage of parameter
Eliot; but if we can avoid ever doing constraints in DTDs, just
generate monolithic DTDs, it would make better things possible.
11:14 AM ET close
-- Ms. Nancy Harrison