Groups - DITA TC Meeting Minutes 12 February 2019 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        Note; I hadn't realized these never made it onto the OASIS site and out to the TC; I completed them right after the meeting last week and submitted them to OASIS, and thought I'd gotten a message back confirming that they'd been added to the documents list.  Anyway, here they are, and this weeks are right behind them.

Nancy


ActionItems:
1. Tom will schedule meeting to review Stan's suggested add'l examples for 2.0.
2. Kris will move non-normative formatting guidance to separate topics to illustrate Chris's suggestion.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 12 February 2019
Recorded by Nancy 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, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois, Dawn Stevens,  


Business
========
1. Roll call
        Regrets: Keith Schengili-Roberts 


2. Approve minutes from previous business meeting:
    05 February 2019:
        https://lists.oasis-open.org/archives/dita/201902/msg00037.html (Harrison, 06 February 2019)
     correction: https://lists.oasis-open.org/archives/dita/201902/msg00045.html (Kimber, 11 Feb 2019)
- Kris; Since Eliot's e-mail does not suggest a correction, I don't know if Nancy can use it to amend the minutes ...  
- Nancy; there was enough info to update it, but no one's had a chance to look at it yet; want Eliot to take a look and make sure he's OK with new version
[held till next week]


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
***ActionItem: Tom will schedule meeting to review Stan's suggested add'l examples for 2.0.
            Kris: 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.
        Eliot: Send mail to list outlining what change should be made to the XSD shell for classification map (COMPLETED)
        Eliot and Kris: Get footer working for CN cover page (COMPLETED) 


5.  New item: Re: [dita] Groups - DITA TC Meeting Minutes 5 February 2019 uploaded
        https://lists.oasis-open.org/archives/dita/201902/msg00045.html (Kimber, 11 February 2018)
        Renamed as Additional thoughts on normative vs non-normative content; formatting versus processing; RFC-2119 keywords
            https://lists.oasis-open.org/archives/dita/201902/msg00046.html (Eberlein, 11 February 2018) 
- Kris; Eliot's comment about the minutes led to a discussion of normative vs non-normative material in the DITA and LwD specs.
- Eliot; I agree with your original correction on what's normative/non-normative. I make a distinction between processing and formatting; processing produces the effective set of source files that result from resolving conrefs, links, filtering, etc. After that is complete, what's left is formatting.  So proceesing is both normative and mandatory (except occasionally for when you do filtering) data processing has to be done according to normative requirements. The 'should' statements we make about formatting are about getting standard results, and simply reflect the considered agreement of the TC.
- Kris; I define formatting slightly differently; I don't know if it's important. If we have section called 'formatting expectations' (FE), we need to have a common understanding of some presentation layer issues. I may think of what Eliot calls 'processing' as pre-processiong, and there's other processing that does deal with presentation layer, e.g. 'shortdesc should be rendered as thefirst body paragraph'.  For those things, we can only make 'should' oor 'may' statements, not 'must' statements.
- Robert; I think it is important to make a distinction between formatting and processing. 
- Alan; this is a change in position; in the early LwD review we got feedback that formatting is never normative; is that not true?
- Robert; what can never be normative is what it looks like on the page; bold, italic etc. but some aspects of formatting (e.g. shortdesc and desc in fig and table) may indeed be normative. 
- Alan; for many topics, the distinction between PE and FE was hard to figure out; I started to favor PE as the default place to put things. For LwD, we're not assuming print rendering, though there could be many outputs, including audio and Braille.  In our opinion, formatting either declares or implies print.
- Eliot; formatting implies a visual presentation; it could be either print or browser; print assumes pages.
- Alan; formatting assumes text; can we agree with that?
- Eliot; it assumes a formatted presentation of textual content, generally by sighted persons.
- Tom; do audio presentation use formatting?
- Alan; Amazon Echo supports text embellishments.
- Tom; that sounds like the same thing as saying text needs to be 18pt
- Alan; I try to use formatting as 'processeors may embellish this in some way as to make it more meaningful'.
- Robert; processors can alsways do that.
- Kris; in any case we need to use the normative words only for normative use.
- Robert; in fact, if those words are used in any non-normative way, the OASIS TAB will hold up the review process until we 'fix' things from their viewpoint.
- Kris; we need to have an understanding on the TC on the difference between FE and PE.
- Tom; I'm having trouble with my own personal opinion around that; it seems like a useful distinction, otoh, it's also useful to apply 'processing' to anything a processor does; so distinction is ambiguous for human readers. Kris used 'pre-processing' for data processing tasks; is that a reasonable compromise?
- Kris; that's a DITA-OT word, and we should use it as such, and with care...
- Tom; but we should identify the different types of 'processing'. 
- Chris; isn't there a 3rd class of things?  I see processing as in 3 parts:
1. processing that operates on XML source, resolving conrefs, links, filtering, etc.
2. processing that does rendering e.g. bulleted lists, shortdesc
3. stylesheet processing that defines fonts, colors, text size, etc.
- Robert; is rendering a better word? when I talk about formatting, I talk about rendering when I mean something that has to be applied.
- Alan; I like that idea. In making e distintions, where's the dividing line? Really, one bucket would be ideal, but if there are 2 buckets, I like rendering better than formatting.
- Tom; or we may just have an overloaded word - processing - 
- Kris; reminder; these 2 sections - PE and FE - are new for 2.0. Part of doing this structure for 2.0 was to bring increased clarity, and to make sure we had the right normative statements that need to be tied to conformance.  This was our first pass   at taking material that had been lumped together and separating it. Robert and I discussed formatting vs. rendering.  We also wondered if we should just exclude anything about rendering from the spec. 
- Robert; as an example, the discussion on bullets might not need to be there.  The question is, for an implementor, 'what do I need to know, regardless of how it's being rendered?', 'what are the rules I need to know to get it rendered correctly?'  Current state is based on the content that existed; it doesn't imply that content was entirely correct or appropriate.  One of my operating assumptions was that most of what ended up in FE will end up getting discarded, because it doesn't belong there anyway.
- Kris; OTOH, we do have some stuff, about generating multiple outputs from common source, that we want to consider keeping.
- Robert; I'm not saying we should get rid of all of it, just some.
- Chris; in working on 2.0 proposals, I've wrestled with these sections; my propopsals mostly had nothing to do with rendering. but, OTOH, when I was considering rendering of mediaobject, while thre were no formatting or processing expectations, there were rendering expectations. In general, I find rendering a more useful word that formatting.
- Robert; I agree, but we want to tread carefully; I thought differently a year ago.
- Kris; our original thought was to use rendering expectations, rather than formatting expectations.  I can't come up with a good answer today, but we do need answers to a number of questions.  What sections are in the spec, and what should those sections contain? What do we mean by those terms?  I think we need a broader definition than Eliot's for processsing in the spec; we'll need to state formally what we mean by processing, and what we mean by a processor.
- Eliot; I'd suggest one way to determine the difference between processing and rendering could be; if behaviour is mandatory, it's processing, if not, it's rendering.
- Kris; but in the spec, we have historically made statements about rendering shortdesc, and I continue to consider them necessary.
- Eliot; but those are still rendering, not processing
- Chris; I agree
- Kris; I think some of my concern is for the purpose of some element ref topics, it's useful to have all statements that include RFC-2119 keywords in a single section; currently, all those are in PE, in FE there are only statemments like 'processors typically do XYZ'; we could just get rid of all of those.
- Robert; but shortdesc is  weird; it often doesn't get rendered because users think it's metadata, so it gets taken out.
- Chris; depending on output, you might or might not show a shortdesc, and there's also how keyref works. 
- Eliot; the spec says 'shortdesc behaves as if it's the first p element of body', but pepople make bizarre choices all the time, so users need to complain to tool providers if their tools are doing things with shortdesc that are problematic.
- Kris; and we provide support for those users by putting a 'should' in the spec.  So, how can we move forward on this item?  We seem to have a consensus from Chris and Eliot to distinguish between PE and RE; PE should have 'must' statements, while RE should only have 'should' or 'may' statements.  Or should we get rid of typographic stuff completely?
- Robert; one question; is this somewhat clearer in your mind now, Alan, even though it's not entirely clear?
- Alan; are multiple buckets necessary and useful to readers of the spec?
- Robert; shouldn't there be at least one for processing, one for rendering?
- Alan; I just need to know to continue with LwD.
- Kris; I think we need mulpiple buckets to deal with stuff that requires RFC-2119 statements, and stuff that doesn't. so the question is 'do we keep non-RFC-2119 content in spec, or do we get reid of it?'
- Eliot; non-RFC-2119 stuff serves the same purpose as examples; it offers guidance even if not normative.
- Chris; I think there's an audience of implementors that needs RFC-2119 material; and another audience of stylesheet writers who needs the rendering guidance.
- Robert; I think they're better served by separate sections myself.  I don't like the idea of one having normative language and one not, but, I'm not sure how to define that.  I would like to define the distinction
- Chris; my 3 buckets would be:
1. normative processing
2. normative rendering
3. non-normative rendering
- Kris; just fyi, OASIS says everything is normative in the spec except for introduction, TOC, examples, notes, appendices, and stuff explicitly labeled 'non-normative'.  If there's something in the spec that's non-normative, we need to identify it.
- Chris; maybe we should have a non-normative topic for each element that requires non-normative guidance, akin to the translation guidance.
- Kris; that sounds like a good idea. 
- Alan; I'm not embracing that for LwD, without further thought, but it might be appropriate.
- Kris; it could be a peer topic to recommendations for translators.  I'd be happy to take an action item to move typographic material into those types of topics, so we have something to look at next week. There aren't that many topics that have this kind of content.  Then we can revisit this next week with examples.
***ActionItem: Kris will move non-normative formatting guidance to separate topics to illustrate Chris's suggestion.


6.  DITA 2.0 stage two proposals
        Vote
            None 
        Continuing discussion
            https://lists.oasis-open.org/archives/dita/201902/msg00037.html 
        Initial discussion
            #29: Rework bookmap design
                https://lists.oasis-open.org/archives/dita/201902/msg00008.html (Sirois, 04 February 2019) 
- Eric; the issue under discussion has to do with one of the changes we wanted to make to bookmap, i.e. to make amendments available at the front of a book aas well as the back.  We originally put it into booklists, but moving amendment out of being a direct child of backmatter created backwards incompatibility, so we decided we couldn't do that. So I"ve now added amendments into frontmatter, so it doesn't break compatibility. But then last week we talked again about adding amendments to booklists, since that's really the natural place for it, and it would be available in both front- and backmatter.
- Robert; I don't get it; letting an element appear in another spot shouldn't break compatibility.
- Eric; but we're moving it from being a direct child of backmatter to a child of booklists. that would break backwards compatibility.
- Robert; couldnt we also leave it in backmatter?
- Tom; what about leaving it in backmatter, but also adding it to booklists?
- Eric, so, having it in 2 spots... ?
- Robert; yeah, so having it in 2 places in backmatter, but only one place in frontmater; that seems like a pretty trivial issue.
- Scott; would PE be different in those 2 different places?
- Robert; no, they wouldn't.
- Kris; this gives us the best of both worlds; at the end of the day, we're not really cercerned with elegance of bookmap design.
- Eric; so consensus is; we add amendments to booklists content model., so we get it in both places in backmatter but in just one place in frontmatter. I'll work on this and we can have it by end of week.
- Kris; will we be ready to vote next week?
- Tom; can we summarize what's in the proposal right now?
- Eric; the other bits are 1) adding glossref to glosslist, 2) adding ditavalref at root of bookmap before frontmatter, and 3) adding element 'mapresources' that allows user to add any specialization of topicref as a child of mapresources (with a resource-only content model, including keyscope).
- Tom; sounds good to me. 
- Eric; a complete description of the proposal will be at DITA/NA.



11:58am ET close 

        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 12 February 2019

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2019-02-20 22:04:59