dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 3 September 2019 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Tue, 17 Sep 2019 02:56:40 +0000 (UTC)
Submitter's message
ActionItems:
1. Robert will add issue with updating spec language on lines wrt whitespace to bugfix list
=================================================
Minutes of the OASIS DITA TC
Tuesday, 3 September 2019
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Scott Hudson, Eliot Kimber, Joyce Lam, Zoe Lawson, Chris Nitchie, Dawn Stevens, Alan Houser, Eric Sirois, Jacquie Samuels, Jim Tivy
Business
========
1. Roll call
Regrets: Keith Schengili-Roberts
2. Approve minutes from previous business meeting:
27 August 2019
https://lists.oasis-open.org/archives/dita/201909/msg00001.html (Harrison, 02 September 2019)
moved by Kris, 2nd Scott, approved by TC
3. Announcements:
None
4. Action items
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC: due 09 April Overdue
13 November 2018
Eliot: Test refactoring of grammar files; due 15 Aug
18 December 2018
Eliot: Investigate issue re earningAggregationsTopicrefConstraintMod.xsd; due 15 Aug
05 March 2019:
Alan: Update DITA 2.0 files for appropriate elements with LwD hint values for @format and create a pull request; due 23 April
09 April 2019
Eliot: Does SVG zip file need to be in techcomm grammar folder? due 15 Aug
Kris and Tom: Finish up any discussion about examples in ArchSpec files
30 April 2019
Kris: Request OASIS Open repository for tools/scripts to aid users in moving to DITA 2.0
28 May 2019
Kris and Robert: Revise content and run it by Eliot (Draft-comment in spec WD03, section 3.3.3, page 37)
Robert: Take an initial look at fixing this (Draft-comment in spec WD03, section 3.4.4, page 52)
Chris: Look at draft-comment in spec WD03, section 8.2.2.19, page 210
18 June 2019
Robert: Work on remaining stylesheet issues; see https://wiki.oasis-open.org/dita/stylesheetBacklog
02 June 2019:
Kris and Deb: Look at existing content in spec about map processing (especially construction of hierachy, rel tables) and make recommendations (COMPLETED by Kris; IN-PROGRESS by Deb)
20 August 2019
Kris: Consider issue #163, discuss with Deb, and make recommendation to TC
Kris and Robert: Check into proposal #9 on keyscope
- [no updates to any items this week]
5. Incompatible specification language for the lines element
https://lists.oasis-open.org/archives/dita/201908/msg00084.html (Anderson, 23 August 2019)
https://lists.oasis-open.org/archives/dita/201908/msg00085.html (Eberlein, 24 August 2019)
https://lists.oasis-open.org/archives/dita/201908/msg00086.html (Kimber, 24 August 2019)
- Robert; this came out of a customer defect; current version of DITA-OT doesn't respect whitespace in lines element, though it used to. Specifically, it's ignoring whitespace in lines. even though xmlspace is set to 'preserve' in that element. My pref is to respect whitespace, but lines is not like the pre element, so what should we do? Apropos of this, I think that for topics about elements that haven't changd since 1.0, we need to be looking at them for 2.0.
- Kris; what are the differences between lines and pre?
Robert; this isn't about a change to grammar file; it has to do with XML language being different from our natural language description in the spec.
- Eliot; I think that whatever is in grammar has to overrule the language in the spec; so xml="preserve" takes precedence.
- Robert; the spec is confusing, the rule that's implied by the XML language is contradictory to the rule that we state in the spec. Any XML tool should respect that definition. So white space should be preserved, but in our final rendering we ignore it.
- Eliot; is smlspace only a directive to parser?
- Robert; it's a direction to all DITA applications, not just parser.
- Kris; let's shift focus; what do end users want and need? I think we need a lines element that respects whitespace, even for poetry. I tried to use it recently in spec output, and was surprised that whitespace wasn't respected.
- Zoe; when dealing with anything but codeblock, we don't need whitespace, but I think I'm in a minority; I think lines should include preserving whitespace.
- Robert; no, you're not in minority.
- Kris; thoughts or comments?
- Eliot; on xmlbase @, I wonder if it's worth including; if you compare it to CSS whitespace property, ours is underspecified. The current version seems to preclude whitespace in 'lines'. If whitespace isn't collapsed in all cases, then you could just have users control their source better; but there's no way to undo it.
- Kris; which seems to mandate us redefining lines in 2.0
- Dawn; what's difference between lines and pre?
- Robert; pre is using monospace, lines is not.
- Kris; and pre is the specialization base for codeblock and messageblock.
- Nancy; Is pre just used for tech content? If so, mayber we should move it from base to tschcomm profile.
- Chris; i've seen it in legal content.
- Eliot; and weather reports...
- Eliot; so if we change lines, then the only difference between pre and lines will be monospace, which means one is just a refinement/extension of the other; so should we make one just a specialization of the other?
- Robert; not sure I want to do that...
- Zoe; my point as well.
- Kris; notable that 20 years after original design of DITA, this is the first time it's coming up. Other than poetry, what other uses of lines would respect whitespace?
- Zoe; I use it sometimes if I don't want an image, but a visual representation of something.
- Kris; I'd use lines to represent output of index entries with secondary/tertiary levels.
- Stan; sometimes used with bibliographic references.
- Eliot; in d4p, I have a formatting domain, with a 'tab' element, for exactly the use case Kris described, with more control over indentation than usual.
Zoe; should lines have an @ that tells you whether you keep whitespace?
- Eliot; that's getting into formatting, and CSS has a whitespace property, or you could create one with @outputclass.
- Kris; are we ready for decision?
- Eliot; would this decision be to change lines?
- Robert; I think this is a bug fix, not a proposal; it just needs to be on project page so we don't lose track of it.
- Kris; it's a bug fix, but we need to ensure it gets into 'changes to 2.0' section, and also is dealt with in migration instructions.
- Robert; I'd propose that we update topic on lines in spec to get rid of language about stripping whitespace, so it works as advertised.
- Kris; any objections?
[none]
***ActionItem: Robert will add this to bugfix list
6. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion
None
Request for feedback
Issue #64, "Redesign hazardstatement"
https://lists.oasis-open.org/archives/dita/201908/msg00090.html (Eberlein, 26 August 2019)
- Kris; wrt hazardstatement, ANSI Standard on hazard statements is not very prescriptive; one of Jang's concerns is that @type attribute we use takes everything from note, and we really want it to just be the 4 standard types. and also we want to include actual ANSI definitions for them (danger, caution, warning, notice). amd should also allow ol and ul within messagepanel. One big queastion is "should messagepanel include the image?" Also, how should hazardsymbol relate to messagepanel? And/or to children of messagepanel? The frustrating thing is we don't have a lot of clear user requirements. So, for TC members on this call; do you or your clients use hazardstatement, and have there been any issues?
- Scott; we're not currently using it, but we might,
- Stan; same for Oracle; people are aware of it, but not using it.
- Dawn; any specific reasons for not using it?
- Stan; for one thing, it wasn't included in some of the CCMSs being used.
- Kris; some hardware docs that were in DITA before 1.2 just used something else, and haven't changed to use it.
- Dawn; one more client of ours has issues with placement of graphic symbols; the use multiple hazard symbols which current model doesn't cover.
- Kris; I went back and looked at original proposals for the hazardstatement domain; they included more than ended up actually being in the domain. I think, based on markup I've seen, let's enable sub-elements of messagepanel to contain symbols; I'd be interested in whether it would work for your clients, Dawn, or if there are still other requirements for alignment and placement.
- Dawn; not sure, let me think about it.
- Kris; Scott; if you could look at your company safety statements that are not in DITA, and lt us know whether the changes I'm proposing would make hazardstatement capable of handling them, that would be great.
- Scott; I can do a mockup and sample coontent. At Pelco, I would have used it, and primarily for ANSI requirements.
- Kris; based on Schneider documents, it seems to be well handled by current domain.
- Scott; yeah, there we just defined consistent styling for what we had.
- Kris; for Apllied Materials, we define a strict order. For small companies who can't customize stylesheets or modify processing, it's hard to use. Also, ANSI doesn't specify an order, just required info. So we may want to ocnsider loosening content model for hazardstatement to 'type of hasard', followed by one of 4 @types, in any order. Also, there are new standards since 1.2 that describe hazards in more detail than ANSI, specifically IEC-IEEE Standard, and guides from Tekom and the Japan Machinery Federation. The difficulty is that we don't have a great deal of experience in this area, so we don't have a good handle on concrete requirements, and so it's a challenge to do good work here.
- Robert; I think we should be careful not to make changes for abstract cases that we may not underStand; we should only look at actual use cases.
- Kris; I agree, a lot of Jang's requirments were general and didn't have use cases to back them up. But I'd welcome anyone who could think about this and give feedback. A lot of folks' responses were driven based on their assumptions of how the domain should theoretically be used, not by practical use cases.
- Eliot; you didn't ask Jang for feedback
- Kris; I did, and I got one reply but none later. I'd welcome any feedback.
- Eliot; I always got the feeling that Jang thought the current structure was a barrier to adoption for some companies. I can reach out to Ediphone (sp?) in europe and see what they need.
- Kris; that would be great; if there are things in the current Tekom guide that we can now do, that would be useful. If we don't have clear reqs, we shouldn't make changes.
- Nancy; so we are planning to do something, just not everything that Jang suggested?
- Kris; we definitely will be making some changes, e.g. limiting @type values; where it gets dicey is how we associate symbols with messagepanel or its child elements.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]