| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 11 March 2014 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 12 Mar 2014 15:59:33 -0700 (PDT)
1. Kris will check with JohnH and the L&T SC to confirm how the release mgmt. domain should be integrated into L&T domain.
Minutes of the OASIS DITA TC
Tuesday, 11 March 2014
Recorded by N. Harrison
link to agenda for this meeting:
regrets: Day, Anderson
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201402/msg00201.html (18 February, Nancy Harrison)
Proposed by Kris, seconded by Dick, approved by TC
Help SC - Stan Doherty reported on the Help SC's current work priorities and plans for spring/summer
1. support DITA 1.3 endgame, especially wrt Help SC's 2 features.
2. write white papers for Adoption TC to support and illustrate the 2 Help SC 1.3 features.
3. go out to lots of ocnferences to beat the drum on DITA supporting Help; the SC now has members on 4 continents, so they can cover a lot of ground.
4. looking ahead; up to now, the SC has been focusing on how does DITA support various ways of tripane help? Post DITA 1.3, we now want to think about how it supports more dynamic, adaptive, responsive efficient types of help, especially apps and mobile.
1. DITA 1.3 progress
- RelaxNG-to-DTD and RelaxNG-to-XSD transformations (Kimber)
- DITA 1.3 grammar files in RNG (Kimber)
Kris; Eliot had committed to 80% completion?
Eliot; actually, I'm 100% done, and circling back to review
- Redesign of "Contains and Contains by" (Anderson)
- First spec review (Eberlein)
Participation so far by Jarno Elovirta, Bob Thomas, Deb Bissantz, Eliot Kimber, Tom Cihak, Jim Tivy, Dick Hamilton, and Kris Eberlein
Kris; there's a list of comments in HTML format
- Download a list of comments generated 11 March 2014 at approximately 8 AM. Note: This HTML file does not accurately reflect status of comments.
- Editors working comments as they are entered and assigning statuses:
o Completed: Spec topic has been updated.
o Accepted: A change to the spec needs to be made, & work is in progress.
o Rejected: Editors do not agree with the comment; no changes to the spec are required. (mostly for errors that are a result of how DITAWeb works)
o Closed: No changes to the spec are required. (Usually in response to a "Looks good; no changes required" type of comment.
2. DITAweb demo:
Commenting on a comment
Viewing status of a comment
Kris did a demo; she noted that to comment on a comment, you need to hover on the little icon at the upper right hand of the original comment; it will say 'add an annotation'
Deb; it was hard to remember to hit 'save'
Kris; you've got to click 'enable editing'
Eliot; also, you can't edit in place; it opens a window at the bottom of the screen and that's where you have to do it.
3. Review #1 progress: When do reviewers and champions expect to complete their reviews? Do we need to make any substitutions?
Kris; has added a table; she went over all the items to see what's done. All named reviewers had committed to review by due date 3/16. Kris noted that proposal owners need to review their own proposals as well as ones they signed up for.
Tom M; shall I sign up for more? and if so, what kind of review should I do
Kris; follow the guidelines below (see link in agenda for more info);
1. Ensure that modified or new spec content associated with DITA 1.3 proposals has been incorporated.
2. Review rework of attributes information in the Language Reference
- Is there content that needs to be edited or wording that needs revision?
- Do the new attribute groupings make sense?
3. make a pass and find all the places we need to mention of RNG, or make the mention generic (replace mentions of DTD/XSD
4. work on RFC-2119 terminology issues
Dick; is there any place where we need to look at style?
Kris; Robert & I have a wiki page where we're logging style issues; if anyone notices a style point, drop me a note and we'll put it up on the wiki page. In gen'l, we've been using the IBM style guide.
Tom; and speaking of style, how to use punctuation for using double quotes? Kris; punctuation should go outside of quotes for XML language elements, but in a looser context, the punctuation goes inside.
4. New item: RFC terminology guidelines
https://lists.oasis-open.org/archives/dita/201403/msg00022.html (Eberlein, 4 March 2014
Kris; The important point is that we didn't use these words correctly previously; we need to correct the usage for 1.3. That means 2 things:
1. making sure they are where they should be,
2. where they're used incorrectly in legacy context, either replace the wrong one with the right one, or a 'non-keyword' version (not upper case or bolded) if that can be done, or better still, change the wording to express the idea without using any of the keywords at all.
5. New item: Release management domain -- Should it apply to maps as well as topics?
Eliot; as I was integrating the proposal to RNG, I noticed that it was only applied to topics, not to maps; I polled the TC list and the proposer (Cihak) said he'd never intended that, others agreed. I need TC consensus to resolve 2 questions:
1. should language be updated to include maps/submaps?
2. should it be integrated into the TechComm doc shells?
Kris; does anyone have any objections?
Tom Cihak; it was always intended to applicable to maps as well.
Kris; We'll do that, and we'll ask JohnH and L&T SC if it should be integrated into L&T maps as well.
Eliot; I think it's supposed to be integrated into L&T topics, but not L&T maps
Kris; I'll check with John and the L&T SC
ActionItem; Kris will check with JohnH and the L&T SC to confirm how it should be integrated into L&T domain.
6. New item: What document type shells should include MathML/equation and SVG domains?
Kris; this wasn't called out in original proposal.
Eliot; right, so my suggestion would be to put it in the Techcomm and L&T (derived from TechComm) shells. Many L&T topic types are specializations of 'concept.'
Kris; This shows a leason learned. We need to amend proposal templates; they need to include a section describing which packages and which doc shells a proposal change needs to be included in.
Nancy; thanks to Eliot for noticing
Resolution; Eliot will include MathML and SVG domains as per suggestion.
7. New item: Normative language and the sort-as element:
The spec includes the following:
"Processors SHOULD expect to encounter elements in the above locations and process them correctly, including the following considerations and precedence rules:"
Kris; DickH asked why we'd used a 'SHOULD' instead of a 'MUST' for this; Joann seconded the request.
Eliot; in gen'l, I tried to be a bit flexible in assigning requirements to a processor; in this case, you're not asking much of the processor, so I wouldn't object to a MUST here.
Dick; I had 2 reasons;
1. any processor could encounter a sort-as, so it has to be able to deal with it in some correct way.
2. if it processes a 'sort', it must process the 'sort-as' the way we say to.
Tom M; it seems like the 'MUST' your asking for is in the wrong place; it should be about the processing,
Eliot; it's only on the sort phrase construction.
Kris; Eliot, that was Dick's point;
Dick; processors must be able to deal with it; if you do a sort, and sort-as is there, you have to do it correctly.
Kris; Joann's email might have indicated that processor MUST support sort-as, but I don't think we can mandate that in the spec.
Kris; we can hash this out if we get into a dialog in DITAWeb.
Dick; I think we just need to reword the intro sentence and we'll be done.
Kris; OK, we can do that.
meeting closed at 11:55
-- Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]