Groups - DITA TC Meeting Minutes 19 June 2018 uploaded

[Tom Magliery<tom.magliery@justsystems.com>]

        Submitter's message
        ACTION ITEMS: 
Bob: Investigate problems with the DITA OT XHTML transformation
Kris: Request publication by OASIS of DITA 1.3 Errata 02
Scott: Look at code examples in the spec and make suggestions for changing one or more of the examples to include

or
Kris: Ensure that the decisions/example/guidance are documented out of the small group meeting with/Robert and Carlos


=================================================
Minutes of the OASIS DITA TC
Tuesday, 19 June 2018
Recorded by Tom Magliery
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/Agenda-19-June-2018

Business
========
1. Roll call
Regrets: Nancy Harrison, Keith Schengili-Roberts, Eric Sirois
Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Don Day, Kris Eberlein, Maria Essig, Carlos Evia, Jang Graat, Dick Hamilton, Alan Houser, Scott Hudson, Tom Magliery, Chris Nitchie, Dawn Stevens, Bob Thomas

2. Approve minutes from previous business meeting:
12 June 2018:
https://lists.oasis-open.org/archives/dita/201806/msg00028.html (Tom Magliery, 14 June 2018)
Motion to accept by Kris
Second by Scott

3. Action items review
08 May 2018:
Eric: Consider e-mail on dita-comment from Stefan Eike and report back to TC
12 June 2018:
Kris: Request an OASIS GitHub repo for committee notes (COMPLETED)
Robert: Test generating committee note HTML with DITA-OT 2.5.4 and latest style sheet code (COMPLETED)
Kris: Reply to post on dita-comment suggesting enhancements to filtering (COMPLETED)
Bob: Get DITA for Technical Content repository functional
Status: Need to have a brief meeting with you (Kris) and Robert before I merge it back to the main repository

4. Spec editing report
Robert, Kris, and Carlos met on 14 June 2018
Developing guidelines and examples for each section of the (reworked) element reference topic

5. OASIS stylesheets
Committee note XHTML fails for Kris on DITA-OT 2.5.4 and Robert on DITA-OT 3.x
Error message: Transformation failed. Fatal error during transformation using C:DITA-OT-2.5.4-OASISpluginsorg.oasis.spec.preprocnumberingxslnumbering.xsl: Cannot write more than one result document to the same URI
Bob: Just in general that's not a good thing. :)
Robert: I suspect something with Saxon (or something like that).
Bob: I think I'll have time to look at it this week.
ACTION ITEM for that
Kris: Note that problems like this affect both spec and committee notes and so when we make changes we have to test both

6. DITA 1.3 Errata 02
Motion text: "I move that the TC approve DITA 1.3 Errata 02, contained in https://www.oasis-open.org/committees/document.php?document_id=63240&wg_abbrev=dita , as an Approved Errata and make it available with DITA 1.3 OASIS Standard."

Formal round-table vote
Motion made by Kris
Second by Dawn
Dawn yes
Kris yes
Bill yes
Maria yes
Robert yes
Dick yes
Alan yes
Bob yes
Tom yes
Chris yes
Carsten yes
Scott yes
Carlos yes
Deb yes
ACTION ITEM Kris: request publication by OASIS of DITA 1.3 Errata 02

7. DITA 2.0 stage three proposals
#85 Add sub and sup to glossentry elements
https://lists.oasis-open.org/archives/dita/201806/msg00024.html (Hudson, 11 June 2018)
Scott: Proposal is basically the same as we have seen before. Proposal identifies the grammar files that need changing (DTD and RNG). Content models bc descriptions are automatically generated, anticipate no changes to documentation. Bc this is an addition, no backward compatibility issues. Although if there are items that people don't want in their content models they may need to adjust their content models to remove them.
Kris: Since we're not including content models in the 2.0 spec we don't need that section in your proposal. Do you think it would be good to modify any of the examples by the elements that are affected?
Scott: We should re-look at any of examples; I'd favour providing better examples. I think I had that in the original stage 1 proposal but didn't include that as a documentation change. We could certainly do that.
Robert: I think not critical to update examples, we already allow a bunch of things in there including . Adding one that has or would be fine.
Scott: I can provide a good example if we want to include that.
Kris: Let's keep that separate from the proposal so as not to slow this down.
ACTION ITEM: Scott to look at code examples in the spec and make suggestions for changing one or more of the examples to include or .
Jang: Adding sub and sup means adding ph element w/all its specializations from highlight domain right?
Kris: Yes, that was our intent, knowing that people may need to implement constraints. A fair number of people will want to implement constraints, but we did think sub and sup were imperative.

#73: Removed delayed conref domain
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/63270/Issue73-stage3-delayedConref.html (Houser, 18 June 2018)
Alan: This is a pretty clean surgical removal of a 1.2 feature. There's little evidence that anyone is using it. It does add complexity to the spec and is a difficult feature to document. Proposal is to deprecate it. People using it can continue to include it in their shells. The proposal is straightforward -- modification of the RNG grammar files, removal of the domain and three elements that comprise the domain.
Kris: note that the TC is not providing a mechanism for maintaining backwards compatibility
Tom: Is this better termed "remove" than "deprecate"?
Alan: Yes, that's the better term.
Kris: Yes, we want to not have anything "deprecated" in DITA 2.0.

Kris: both of these items will have a vote next week to pass Stage 3, then they will go into the spec and grammar files.

8. XSDs for DITA 2.0?
https://lists.oasis-open.org/archives/dita/201806/msg00029.html (Eberlein, 18 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00030.html (Hudson, 18 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00031.html (Anderson, 18 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00032.html (Eberlein, 18 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00033.html (Jang Graat, 18 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00034.html (Thomas, 18 June 2018)

Kris: We've talked a number of times about what we want to ship. We'll ship RNG, that's normative. We want to ship modular DTDs. We have not had a real conclusion about XSD. Options include not shipping, or shipping one that's automatically generated but not modular. Maybe we can come to a decision today.
Scott: from a support perspective the fewer schemas we release the easier it is for us to maintain. my question is whether or not the authoring tools listed have alternative support for other schema types. I'd rather see XSD go away.
Kris: Xopus/XDL and Xeditor I believe ONLY run on XSD. I think Fonto might fall in this category but I'm not sure.
Chris: Xopus also requires a monolithic XSD last time I checked. (So if we ship structured modular ones that wouldn't help.)
Kris: SDL changes the OASIS XSDs anyway.
Kris: Does anyone know about Fonto?
Jang: I think they have their own process to change the schemas (whatever they are) to their own format.
Kris: We know we can't generate XSDs automatically, that has always been a pain point for us.
Robert: There are many reasons not to ship modular XSDs. Even in a perfect world where we could generate them, there are some aspects of DITA that can't be handled with modular XSDs. But if we hav ea simple process for generating a modular XSD, I don't think it would hurt to ship that.
Tom: Do we even have enough confidence to know whether a monolithic XSD supports all the DITA features we want?
Robert, Kris: good point, possibly not
Kris: Just to clarify, we would need an XSD for each document type
Bob: I think providing a monolithic XSD would dissuade people from doing document shells. And making vendors provide their own schemas provides momentum against
Robert: I'm not sure I'm agree, I think no one who's not
Bob: If we offer up monolithic XSDs, some vendors would offer tools
Robert: but that's true if we ship any XSD monolithic or not. Not a realistic chance that people will continue maintaining modular XSDs.
Bob: I'm saying it makes it easier for vendors to do the wrong thing and we support 2.0, too bad you (customer) decided to specialize/constrain it.
Jang: That's already true today. I don't think the DITA TC can solve that. The tools vendors need to solve it. I'm solving it for FrameMaker which requires EDD. If I can do it for FM then I don't see how Xopus couldn't be doing it for their stuff.
Kris: Bob, let's just imagine that we do produce a monolithic XSD and ship it. If we make it clear that it's generated/provided as a convenience, I think unlike how we feel about our RNG/DTD we don't want anyone to make any modifications, I think we would have to say "this is an artifact, do what you want with it".
Robert: I disagree slightly. I think the message we want to send is not worth the effort ot work with XSD in DITA becaus ethere aren't going to be any entities you can change to have your change ripple outward. Our message is it's too tedious/error-prone to define specializations in XSD. If your tool requires it, here, we've generated one, but do specializations in RNG.
Kris: if we even want to try to generate a monolithic XSD we need to have a good way to do it, and a good way to ensure that it defines the same content models and structures as RNG or DTD.
Bob: Perhaps we could have a committee note about how to generate XSD, and not include it with what we ship.
Jang: I don't see why we need a committee note. If people can figure it out, they can figure it out. There are only a few companies who need this.
Tom: I agree that we should drop XSD
Kris: I know IXIASOFT uses Xeditor for their web component, and it requires XSDs. Eric has successfully generated XSDs from DTDs using Trang and they work. So I think that type of process could continue for 2.0. If SDL hacks the OASIS DTDs anyway, then they've already got a chunk of development work to do.
Kris: My opinion is we should definitely say we're not shipping modular XSDs. Either we could not ship XSD at all, or if folks on the TC can come up with a way to create/test monolithic XSDs, then we could consider that later if someone has time/energy to build them.
Robert: for me the only real benefit of a monolithic XSD is that it lets us say "Look you can still do DITA with XSD".
Tom: who wants us to say that?
Robert: That's the point ... I don't think there's a compelling audience for that anymore.
Kris: Any objections to not shipping modular XSDs
[silence -> no objections]
Kris: Do we want to ship NO XSDs, or do we want to leave a little wiggle room by providing a monolithic XSD (if someone can come up with a way to create/verify) these?
Bob: I'm ok with either option
Alan: I'm ok with doing a clean break here.
Kris: I'm going to do a round-table "vote".
Dawn? Drop XSD entirely
Bill? Drop it
Maria? Drop it
Robert? Drop it
Dick? Drop it unless someone is willing
Alan? Drop it
Bob? Drop it
Tom? Drop it unless someone is willing/able
Chris? Drop it
Carsten? Drop it
Scott? Drop it
Carlos? Drop it
Deb? Drop it unless willing/able
Kris: This gives us a resounding answer. Let's publicize our decision. If someone says they want to pony up the time we can revisit, otherwise we are not shipping any XSDs for DITA 2.0. Any objections? [silence]

9. DITA for Technical Content
Action items:
GitHub repo functional?
Spec:
Restructure element reference topics using new DITA 2.0 format
Kris: this will be the first work item when the repository is available.
ACTION ITEM: Kris: Ensure that the decisions/example/guidance are documented out of the small group meeting with/Robert and Carlos

10. Proposals:
Enable steps to nest (Anderson, stage 3)
Bookmap enhancements (Sirois, stage 2)
New diagnostic elements for troubleshooting topic

Kris: I've just noticed that we have these new proposals that affect this. So having the repository functional is kind of a prereq for us to implement these proposals.
Any questions or thoughts?
I will just bring up one question we had from Amber, she wondered whether this was the best name for this package.
Alan: I agree that has always troubled me, although I have no alternate.
Chris: Something like "commons" comes to mind, it does seem to be used as the "default" DITA.
Tom: general agreement with what's being said.
Kris: Let's close with a request for people to think about this, maybe we need a new name.
From an OASIS perspective, whatever we call this thing, we can have the numbering be 2.0. We were afraid we would need a 1.0 name, but whew, we don't.
Robert: I really was worried that our first one of these branch-specs would have to be called 1.0, so this is a relief.

12 noon ET close
-- Mr. Tom Magliery

Document Name: DITA TC Meeting Minutes 19 June 2018

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Mr. Tom Magliery
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2018-06-21 01:19:22