[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes for March 19th DITA TC call
================================================= 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]