Eric Sirois was not present.
Also, in regard to the following:
- Kris: ... So we may want to ocnsider loosening content model
for hazardstatement to 'type of hasard', followed by one of 4
@types, in any order.
Should read "So we may want to consider loosening content model
for hazardstatement to <typeofhazard>, followed by
<consequence> and <howtoavoid>, in any order.
Key changes in blod.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 9/16/2019 10:56 PM, Nancy Harrison
wrote:
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
|