← Prev in month ← Prev in thread
Next in thread → Next in month →

Groups - DITA TC Meeting Minutes 19 June 2018 uploaded

From
Tom Magliery <>
Date
2018-06-21T08:20:05+00:00
ID
Thread
Groups - DITA TC Meeting Minutes 19 June 2018 uploaded
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
← Prev in month ← Prev in thread
Next in thread → Next in month →