Groups - DITA TC Meeting Minutes 9 Febuary 2016 uploaded

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

        Submitter's message
        ActionItems:
1. Eliot will create 'truck' subdir in OASIS SVN and move everything from 1.3 spec except latest changes into it. 



=================================================
Minutes of the OASIS DITA TC
Tuesday,  09 February 2016
Recorded by Nancy Harrison
link to agenda for this meeting:	
https://wiki.oasis-open.org/dita/PreviousAgendas


Regrets:  none 


Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201602/msg00004.html (Nancy Harrison, for 26 January 2015) 
Proposed by Kris, seconded by Dick, approved by TC

Subcommittee Reports
	none

Announcements
    	None


Business
========
1. Action items
    26 January 2015
        Eliot to add tags to SVN
        Eliot to upload fixes to XSDs and DTD catalog files
Eliot; both done; created tags in SVN, would like to further make one more change to create a subdir called 'trunk' and move everything except latest stuff into it, which will make it in line with standard SVN practice.
[TC agreed with that]
ActionItem:
Eliot will create 'truck' subdir and move everything but latest changes into it. 
        Michael: Contact Lightweight DITA SC about an OASIS open repository 
Michael; sent email, but no discussion yet; will have to wait for next meeting to discuss


2. Continuing item: Tentative DITA TC agenda for 2016:
    Reflections on DITA 1.0-1.3
    Continued work on TAB comments:
        Normative and non-normative wording
        Hyperlinks for all element and attribute mentions
        Conformance statement (will handle as part of item below) 
    Focus on conformance statement and new OASIS guidelines
    Lightweight DITA
    dita.xml.org
    DITA 2.0 planning
    DITA 1.3 errata planning
    OASIS open repositories
    Committee notes
    Interoperability demo, perhaps at tcworld 2016
    Upgrade DITA-OT plug-ins to work with DITA-OT 2.2.2 or later 
[this is just a note on what's ahead]


3. Update on OASIS press release (Eberlein)
Kris; the press release went out; we got the same number of comments as we had for 1.2. Thanks to Tom for updating the TC's public page.


4. New item: Question for the TC
    https://lists.oasis-open.org/archives/dita/201602/msg00003.html (Chet Ensign, forwarded by Eberlein, 8 February 2016) 
Nancy; see my note in response; the requirements that disallowed our being able to put the information about the 3 editions in a prominent place on the cover page, necessitating the committee note, were a problem and created a lot of extra work.
Tom; Kris and Robert might know the most, but the TAB comments that came at the last minute seemed out of left field; we weren't able to expect them, and they came too late to address.
Kris; I experienced them as 'gob-smacking' as well.
Robert; we have communicated that to Chet already; we thought these were 'official' and had to be addressed, which they are not.  Our advice to Chet was to get them much earlier.
Kris; we told Chet we would have liked to have that kind of review much earlier.  And even if we have mentioned it before, this is the time to produce a consolidated list.  I find the complexity of what they require on the cover page to be a problem.
Bob; the sad thing is that after all of that, it's very difficult to find the all-inclusive PDF off the OASIS site. 
Nancy, so it's both difficult to produce, and also non-useful to readers.
Kris; it requires at least 4-5 clicks to get to the spec.
Bob; We should ask Chet to try himself to get to the spec without any 'insider' knowledge.
Don; we did ask people in the DITA community to put links on their websites to the spec in order to get google to put it near the top of a search.
Tom; i think the press release from Chet explicates the situation as well as anything, so I put a link to that on the public DITA page.
Robert; some of this is self-inflicted, since we were the ones who went to the 3 editions mode. but OASIS does need to be able to handle such things.
Kris; I'll put an item on next week's agenda on what we can do to make things easier to find for users.
Bob; I'd like to know that all the OASIS publication requirements that lead to real work.(e.g. syntactical rules for naming conventions) 
Robert; I'm not sure there's much meaning for the various tokens (csd, prd, etc), but they require several different levels where spec could change at the different levels of approval.  The problem is that they require the links in so many places across the cover page that it's hard to keep them straight.
Kris; also, the extensions were not the same across the process, e.g. 'committees draft (csd) or prd, followed by a numeric, so at every stage of the game, we had to adjust the file naming. And the tokens and muberics have to appear not only in the link, but as the actual file name.
Robert; because every pre-final spec could have more than one revision...
Kris; But none of this is documented anywhere; it's all in Chet and Paul's heads.... 
Robert; yes, it definitely needs to be laid out more. we're kind of an outlier, but it would be nice to make this easier for outliers.
Kris; I wish OASIS had published style specs; everything is controlled through the Word template, which can change. 
Kris; otoh, working with Chet was great; he was always there to help us.
Robert; right; he was always trying to help, very different from 1.2.
Don; could we have used relative links?
Robert; not for the cover page or PDF output.
Kris; keys were good for actual link text, but not for @hrefs.
Kris; one other thing is that OASIS's issues official documents, but we never get notice that a new set of guidelines is out.  There were new draft directives for conformance statements that I didn't find until August. They need to do a better job of communicating that they have new draft/official guidelines.
Don; the DocBook TC might have experiences that could inform our perspective.
Scott; yes; the spec versioning has really plagued the DocBook TC as well; we've even encountered it on this DocBook 5.1 process.  
Kris; and did you have to revise the stylesheet transforms?
Scott; yes, Norm did most of it, but they did have to be refactored.
Kris; we need early/often notice of changes
Robert; they tend to not take into account folks not using their Word template.


5. New item: TAB comments about normative and non-normative wording
    See summary in https://lists.oasis-open.org/archives/dita/201508/msg00074.html ; search for "Normative and non-normative wording"
    Seven TAB comments:
        c030: https://issues.oasis-open.org/browse/TAB-1264
        c031: https://issues.oasis-open.org/browse/TAB-1267
        c032: https://issues.oasis-open.org/browse/TAB-1268
        c049: https://issues.oasis-open.org/browse/TAB-1281
        c055: https://issues.oasis-open.org/browse/TAB-1287
        c056: https://issues.oasis-open.org/browse/TAB-1288
        c057: https://issues.oasis-open.org/browse/TAB-1289 
    Keyword Guidelines for OASIS Specifications and Standards
        TAB-approved document, 2014-02-21
        https://www.oasis-open.org/policies-guidelines/keyword-guidelines 
Robert gave summary; these were some of the most disheartening comments; they did keyword searching on actual keywords (upper-case) and instances of those same words/phrases in lower-case as well as similar words/phrases - 'must/must not', 'have to' 'might/might not', 'need to', and 'can/can not'. They thought there were too many of them - all should be findable in the conformance clause. Said 'you need to find all and decide if they're normative or not'.
Kris; And there were huge numbers of them; e.g. found 287 'must/must not', >400 usages of 'can/can not', etc.  
Robert; we looked at every one, over a few days. In some cases, where they were really not normative, we changed wording to make it clear.  In some places, the non-normative should really have been normative, but since there'd been no change since 1.0, we left them alone.  But they have a valid point. 
Kris; In looking at lower-case instances, we did do some substitutions, Going forward we need to look at their guidelines more carefully, and document our practices and rationale. [I did some documentation on this]  Moving forward, we need to look at some of these legacy topics and decide what to do. Should things go in langref? in non-normative companion doc? For implementors looking for rendering reqs, there's no easy way to find them in spec. 


6. New item: How should the spec handle statements about rendering expectations?
    https://lists.oasis-open.org/archives/dita/201602/msg00006.html (Eberlein, 9 February 2016) 
7. New item: Need for work on conformance statement for future versions of the spec
    Overview (Robert Anderson)
    TAB comments:
        See summary in https://lists.oasis-open.org/archives/dita/201508/msg00074.html ; search for Conformance
        https://issues.oasis-open.org/browse/TAB-1278
        https://issues.oasis-open.org/browse/TAB-1280
        https://issues.oasis-open.org/browse/TAB-1283
        https://issues.oasis-open.org/browse/TAB-1284
        https://issues.oasis-open.org/browse/TAB-1286
        https://issues.oasis-open.org/browse/TAB-1290
        https://issues.oasis-open.org/browse/TAB-1291 
    [OASIS] Guidelines to Writing Conformance Clauses:
        Reviewed and revised on 25 April 2014; not yet approved
        http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html 

[combined discussion on above 2 items]

Kris; this is about formatting more than processing. 
Eliot; We have a clear intent in the spec, but for many elements where the statement is just about the rendering, that's just a suggestion; it's not our place to stipulate and make it normative.
Robert; what about the quote element?
Eliot; the point of the quote/lg element is to allow that formatting. so any rendering of quotes is qualified.
Kris; let's keep it simpler; if I'm looking at draft-comment or required-cleanup or q/lg, it's ok to have normative statements about them.
Eliot; what I'd like to see, is that for rendering we can't require something normatively, but we do want to have what we expect to see.
Kris; so e.g. authors shouldn't add punctuation when you use the q/lq element?
Robert; I lean towards Kris; a lot of tools do not properly display quotes, so if I use quotes, I don't think there are clear-cut answers
Kris; it gets even more complicated when we talk about required-cleanup. We say processors 'by default' do not render it.
Eliot; But that language turns the MUST into a SHOULD, because 'by default' means there are other options. We can't mandate how people use DITA content. so having a 'MUST' means any other behavior is forbidden.  What we need is for the MUST to be accurate, so e.g. processors MUST provide the option (and it MUST be the default?) of hiding draft-comment. 
Robert;  The goal is that if someone does anything else, they have to work at it.
Eliot; but that's still not a MUST on the option, it's not absolute.  Rendition can't be normative. So we can only be very clear in our intent.
Kris;  We do make normative statements about processing for rendition. There's a distinction between the categories of processing, final rendition or pre-processing.  For example in abbreviated-form, there are a lot of normative procesing statements that don't touch on output rendering, but are for pre-processing.
Robertl we make allowances for not knowing how it will appear.
Eliot;  The only reason to make something normative, is so we can test it with a processor. but most of DITA isn't like that, so it shouldn't be normative
Robert; I disagree with that statement.
Don; I've processed a lot of data that isn't documents, and some of the normative statements aimed at processing documents don't apply.
Keith; not all DITA is for PDF docs, so there could be use cases that we can't think of, where such things as draft-comment or required-cleanup need to be rendered.
Kris; I agree, but part of why we make normative statements is to assure consistency in people's experience as they move between vendors.
Robert; I only disagree with Eliot's saying they need to be quantifiable; we need to deal with expectations.
Eliot; the statemens of expected behavior need to be there, they simply don't need to be normative.
[to be continued next week]
 

12:01 PM  ET Close 




        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 9 Febuary 2016

---

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: 2016-02-09 09:41:24