minutes for March 19th DITA TC call

Hi,

the OASIS web site is giving me trouble in filing the minutes, so I'm sending them out in this mail.Â I'll continue to try to get them into the documents section on the OASIS site, but given that it's already been a day of trying, I don't want them to be unavailable.

Nancy

_____________
Nancy Harrison
Infobridge SolutionsÂ
nharrison@infobridge-solutions.com

ActionItems:
1. Michael will bounce ideas around and come back with concrete proposal, which will map both @class and @outputclass to LwD @class
2. TC members should look at MQTT conformance material (link from Kris's mail) and think about whether we want to do ours that way.
3. Kris will post latest OASIS conformance reqs

=================================================
Minutes of the OASIS DITA TC
Tuesday, 19 March 2019
Recorded by Nancy Harrison
link to agenda for this meeting:ÂÂÂ
https://wiki.OASIS-open.org/dita/PreviousAgendas

Attendance:
Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois, Jim Tivy, Michael PriestleyÂÂÂ ÂÂÂ Â

Business
========
1. Roll call
ÂÂÂÂÂÂÂ Regrets: Carsten Brennecke, Alan Houser

2. Approve minutes from previous business meeting:
ÂÂÂ 05 March 2019
ÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201903/msg00014.html (Harrison, 07 March 2019)
Moved by Kris, 2nd by Bill, approved by TC

3. Announcements:
ÂÂÂ New TC members: None

4. Action items
ÂÂÂ 21 August 2018
ÂÂÂÂÂÂÂ Kris & Robert: Perform the best edit of multimedia topics that they can do in time available; due 18 September
ÂÂÂ 11 September 2018
ÂÂÂÂÂÂÂ Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC
ÂÂÂ 13 November 2018
ÂÂÂÂÂÂÂ Eliot: Test refactoring of grammar files
ÂÂÂÂÂÂÂ Spec editors incorporate changes from DITAweb review (Significant progress, very near to completion)
ÂÂÂ 18 December 2018
ÂÂÂÂÂÂÂ Eliot: Investigate issue re earningAggregationsTopicrefConstraintMod.xsd
ÂÂÂ 22 January 2019
ÂÂÂÂÂÂÂ Kris and Robert: Schedule meeting to plan moving forward on implementing complete DITA 2.0 proposals
ÂÂÂ 29 January 2019:
ÂÂÂÂÂÂÂ Robert, Tom, Scott: Review examples that Stan suggests adding to DITA 2.0 spec
ÂÂÂÂÂÂÂ New owner Carlos: Set up regularly scheduled calls between DITA 2.0 and LwDITA spec editors
ÂÂÂ 05 February 2019:
ÂÂÂÂÂÂÂ Kris: Add fix to 'xmlnamespace' topic to list of things to fix in 2.0.
ÂÂÂ 12 February 2019
ÂÂÂÂÂÂÂ Tom: Schedule meeting with Robert and Scott to go over the additional examples Stan proposed for DITA 2.0
- Tom; meeting scheduled for 3/25 but has not yet occured
ÂÂÂ 19 February 2019
ÂÂÂÂÂÂÂ Alan and Tom: Have functional stylesheets for DITA spec (PDF and XHTML) by DITA NA conference
ÂÂÂ 05 March 2019:
ÂÂÂÂÂÂÂ Alan: Update DITA 2.0 files for appropriate elements with LwD hint values for @format and create a pull request
ÂÂÂÂÂÂÂ Carlos & Alan: Select three element reference topics that exist in both LwDITA and DITA 2.0 for LWDITA and DITA editors to work on.
[no other updates]

5. Review of DITA 2.0 proposal deadlines
ÂÂÂ https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; any updates? any items for 3/12 done? (2/12 items are done)
- Robert; I'll push mine out another week to 3/26
- Eric; the 'deprecate' proposal is out for review to Robert and Chris
- Kris; are there target deadlines for review?
- Eliot; would like to get things back by next week, but...
- Robert; I'll try to have back by next week.
- Chris; as will I.
- Kris; should we put off copy-to for 2 qweeks?
[copy-to will be put off for 2 weeks.]

6. DITA 2.0 stage two proposals
ÂÂÂÂ Vote
ÂÂÂÂÂÂÂ Issue #34 Remove topicset and topicsetref
ÂÂÂÂÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201902/msg00064.html (Kimber, 26 February 2019)
moved by Eliot, 2nd by Bill
Results:
yes votes:ÂÂÂ ÂÂÂ 12 (Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois)
no votesÂÂÂ ÂÂÂ 0ÂÂÂ ÂÂÂ Â
ÂÂÂÂÂÂÂ Issue #21: Resolve inconsistent class values for shortdesc, linktext, and searchtitle
ÂÂÂÂÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201902/msg00065.html (Kimber, 26 February 2019)
moved by Eliot, 2nd by Tom
Results:
yes votes:ÂÂÂ ÂÂÂ 12 (Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois)
no votesÂÂÂ ÂÂÂ 0ÂÂÂ ÂÂÂ Â
ÂÂÂ Continuing discussion
ÂÂÂÂÂÂÂ None
ÂÂÂ Initial discussion
ÂÂÂÂÂÂÂ None

7. DITA 2.0 stage one proposals
ÂÂÂÂÂÂÂ None

8. Continuing item: Reworked intersection topics; "Rendering expectations" and appendix topic for "Formatting expectations"
ÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201902/msg00053.html (Eberlein, 19 February 2019)
- Kris; at our mtg in Feb, Chris suggested we move formatting expectations (FE) out of language ref topics and into an appendix.Â Can anyone summarize what happened the last time we discussed this?
- Hancy; general sense was that an appendix is somewhat less useful to users, but more helpful to implementors.
- Kris; right; so we need to make a decision today.we have 3 choices about FE:
1. leave them out entirely.
2. leave FE material in the body of ref topics, but mark each FE as non-normative.
3. aggregate all FE material in an appendix.
- Chris; I like the appendix option; it concentrates non-normative info in one place, and keeps ref topics cleaner. I think the spec, including language ref, is for implementators first and users second. Most of the FEs we have will be known to authors and expected, so users wouldn't need to go there to find these things out.
- Robert; I like the appendix approach from implementation perspective. As an author, my tools will be better when my tools implementors have easy access to this stuff.
- Bill; for most part, users don't look at the spec, implementors alwaysy do.
- Kris; formatting is so implementation-dependent. having an appendix would be useful for company info architects to check out when they're deciding on their own formatting choices.
- Hancy; and the FEs we put in are the ones that are so standard that they're expected.
- Tom; right, 90%-99% of people do things thw way we document in the FEs.
- Chris; that's almost an argument for not having anything, but we should have something.
- Tom; one real need for this appendix is if somewhere there's an info architect who needs to argue to their team about rendering expectations.
- Chris; so we need to look at our expedtations wrt things like e.g., dlhead.
- Kris; all of this FE material has been in spec since 1.0. Only changes made were in 1.3, when it was pulled it out into its own section, and now it's in an appendix.
- Kris; so do we want to go ahead with this, or hold it for a TC mtg where Alan is present?
- Robert; we can go forward; 2 wks ago he wasn't so opposed as to want to stop it.
- Deb; I've been looking at the appendix to see if this is complete, and it looks as though it is, so I'd say go with it.
- Carlos; Alan says [via text] that he'd prefer it in topics, but "it's not a hill he'll die on".
- Scott; as long as there is a place where users can find it, that's ok with me.
- Kris; hearing consensus that we should go ahead on this.

9. Stylesheets
ÂÂÂÂÂÂÂ OASIS has agreed to build actual style specifications, with our help
ÂÂÂÂÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201903/msg00012.html (Eberlein, 04 March 2019)
ÂÂÂÂÂÂÂ Updates on committee note:
ÂÂÂÂÂÂÂÂÂÂÂ Now runs on DITA-OT 3.3 (both PDF and HTML5
ÂÂÂÂÂÂÂ Update on spec:
ÂÂÂÂÂÂÂÂÂÂÂ Now runs on DITA-OT 3.3
- Kris; OASIS has decided to build style specs with our assistance; we've had meetings with them and back-and-forth email. It's mostly done for CN, then we'll move on to specs.Â Our CN now runs on DITA-OT 3.3 and the spec will also run on that, though they produce some errors and we don't get exactly the OASIS formatting we need. If we can get OASIS to have a style specification, so we'll be at a point where they understand that their Word templates are non-normative.
- Tom; how will this impact the action item Alan and I have for 3/19?
- Kris; it means that the spec actually runs, but it doesn't produce output that's compatible with OASIS styles; I'm trying to drive OASIS on this.
- Tom; who is working on that besides you?
- Kris; me, Alan, BobT when he feels up to it.Â The backdrop is we've always wanted to be able to make our stylesheets available to other TCs, but they've always been glitches and not well-documented, and never could keep up with OASIS's changes to it's Word templates, which they often didn't let us know about untilwe put of a spec that didn't match them.Â Hopefully, we can make the OASIS style-conforming stylesheets available this year.

10. New item: Mapping class attribute in LwDITA authoring formats
ÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201903/msg00022.html (Evia, 18 March 2019)
- Carlos; we would like MDITA to be fully independent of HTML tags. we have a mapping for @outputclass to HDITA, but none for DITA @class. So we're looking at that. We think we do need one.
- Michael; it looks like the decision got made to un-namespace DITA @class, but no discussion of @outputclass. We already havev outputclass mapped to HTML @class, so how should we map @class?
- Hancy; couldn't you use both in HTML?
- Michael; HTML has @class but no @outputclass.
- Tom; so is HTML @class semantically more like @outputclass that @class?
- Michael; in HTML @class gets used for both types of data.
- Chris; what about using a namespace? In a discussion 2 years ago, we were trying to decide between hd and hdita as a namespace...Â
- Chris; my initial thought was "why do you need DITA @class if you're never going to be specializing", but if you're using specialization at all, you need some place to record it.Â HTML @class conventions are very different from DITA @class conventions structurally. but the info in both are similar; 'this is this kind of x, y, z,' So I'd be intereeted in mapping @class to something in HTML. Ideal would be to map both @class and @outputclass to HTML @class, but lots of problems with doing that.
- Michael; I think that's a good point; going thru a mapping exercise; doesn't have to be identical as long as we can round-trip. We couldÂ say something like "if HTML @class values contain a slash, we'll treat them as specializations, and if not, they're @outputclass".
- Chris; I think that makes sense, barring a review of CSS; I've never seen a slash in HTML @class.
- Eliot; CSS would allow for that; that was part of design work on DITA 1.0 @class.
- Eliot; But there's a risk that if someone has an arbitrary @class value with a slash in it, they'd have problems.
- Chris; this is where namespacing makes sense; if the namespace is there, you know to change it to a specialization value.
- Michael; so if we want to go with idea of mapping both @outputclass and @class to HTML @class value, I'm thinking that we just need to do a bit of research; if slash is weird enough to be a DITA signifier, we just need to know that it will do the job; otherwise, we can use a signifier to distinguish DITA @class from DITA @outputclass values.
- Tom; i think it will be too hard to do research to make sure of slash; I think prefix-matching is easier that matching on a particular string containing a slash.
- Michael; in DITA @class with slash, stuff before the slash is already sort of a namespace, protecting it from a collision that has a really small likelihood in any particular doc. We might try to think of a way to get rid of the value before slash; e.g instead of 'li/step', it could be lwd:step.
- Tom; the risk of clashing within a doc is minimal, so if you could capture the fact that you're working within a single document; can a transformer find info they need and find relevant info?
- Michael; that works if only one specialization is in effect; but there would be issues if there were more.
- Chris; but the tag name ust be unique within the shell.
- Tom; we don't have a way to publicize name of a shell, do we?
- Michael; we do; it goes in the root element @class element; but name for the name you're pulling in doesn't tell you what elements are in it; that's what @class is for.
- Chris; the more convoluted these rules get, the harder it will be for users to get it right, so that's an issue...
- Michael; for Markdown, we're expecting it to be human-typed; for HDITA, users will use tools, but for Markdown, everything we put in will have to be typed by a human.
***ActionItem; Michael will bounce ideas around and come back with concrete proposal, which will map both @class and @outputclass to LwD @class

11. New item: Conformance content in the MQTT Version 5.0 (candidate) spec
ÂÂÂÂÂÂÂ https://lists.oasis-open.org/archives/dita/201903/msg00020.html (Eberlein, 14 March 2019)
- Kris; look at the way MQTT TC has handled conformance; we might want to follow their lead
***ActionItem; TC members should look at MQTT conformance material (link from Kris's mail) and think about whether we want to do ours that way.
***ActionItem: Kris will post latest OASIS conformance reqs

12 noon ET close

dita message