OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Groups - DITA TC Meeting Minutes 2 July 2013 uploaded

Hi Nancy,
 You forgot that we completed the discussion of 13114 and it is ready for a vote next week.

Sent from my iPad
JoAnn Hackos
Comtech Services Inc
710 Kipling Street Suite 400
Lakewood CO 80215

On Jul 2, 2013, at 11:58 AM, "Nancy Harrison" <nharrison@infobridge-solutions.com> wrote:

> Submitter's message
> [ActionItem: (All) adjust Trello target dates as necessary]
> Minutes of the OASIS DITA TC
> Tuesday, 2 July 2013
> Recorded by N. Harrison
> regrets: Chris Nitchie, David Helfinstine, Adrian Warman,
> Standing Business
> =================
> Minutes from last meeting: 
> https://lists.oasis-open.org/archives/dita/201307/msg00014.html (25 June, Harrison) 
> Proposed by Kris, seconded by MichaelB, approved by TC
> Subcommittee Reports:
> Help SC
> Stan reported that the SC has renewed its activities; it is picking up 2 previously open proposals (originally numbered 39556 & 39557), 39556 on specializing a element, and 39557 relating to a context help window management specialization. They expect to have both proposals ready for Stage 2 vote by August, as per the current 1.3 deadlines.
> The SC is looking at producing documentation for its work in the form of white papers rather than specifications; once they wrap up the work on the new proposals, they'll start working on a series of white papers.
> - Kris; Will the white papers come out of Help SC or the Adoption TC?
> - Stan; The Help SC has an 'adoption' group, and the white papers we're thinking of seem to fit within an adoption context; we'll decide later on who should publish them, once we've written them.
> Announcements:
> none
> Business
> ========
> 1. DITA 1.3 progress
> Progress between 24-30 June: https://lists.oasis-open.org/archives/dita/201307/msg00033.html (Eberlein)
> Update on current deadlines: http://chris.nitchie.com/trellotrack/#511a73d76ee890a51c0007ed
> Trello Board: https://trello.com/b/gPKH0OcF
> Kris reported; good progress in last week's meeting and over the week.
> Upcoming: 13108 (Priestley) due, Michael will adjust the target dates
> Re: progress of TechComm SC on troubleshooting elements; Stan noted that Bob Thomas needs one more week, he thinks we'll see the proposal next week for discussion. Kris asked that they adjust deadline in Trello.
> 2. DITA 1.3 proposals, stage 2: http://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage2
> Holding area for "Ready for discussion":
> Proposal 13105: Allow within lists (Kimber)
> https://lists.oasis-open.org/archives/dita/201306/msg00067.html (DITA)
> https://lists.oasis-open.org/archives/dita/201306/msg00068.html (HTML)
> https://lists.oasis-open.org/archives/dita/201306/msg00069.html (PDF) 
> Proposal 13120: Vocabulary for publishing process details (Kimber)
> https://lists.oasis-open.org/archives/dita/201306/msg00093.html (Kimber, implementation details not previously discussed)
> https://lists.oasis-open.org/archives/dita/201306/msg00089.html (DITA)
> https://lists.oasis-open.org/archives/dita/201306/msg00090.html (HTML)
> https://lists.oasis-open.org/archives/dita/201306/msg00091.html (PDF)
> https://lists.oasis-open.org/archives/dita/201306/msg00092.html (Toolkit plugin) 
> Ready for vote: Voting options are "Yes," "No," "No objections," "I don't understand the proposal," and "I have reservations"
> Proposal 13121: Reuse of structural specialization fragments (Priestley)
> https://lists.oasis-open.org/archives/dita/201306/msg00065.html (HTML)
> https://lists.oasis-open.org/archives/dita/201306/msg00064.html (DITA) 
> Voting Results: 
> yes:	 Anderson, Bissantz, Boses, Day, Doherty, Eberlein, Hackos, Hamilton, Harrison, Kimber, Myers, Priestley 
> no. obj.:	Buchholz, Magliery
> Proposal was moved by MichaelP, seconded by Don, approved by TC 
> Ready for discussion:
> Proposal 13103: Deprecate @print and replace with more general mechanism (Kimber)
> https://lists.oasis-open.org/archives/dita/201306/msg00057.html (DITA)
> https://lists.oasis-open.org/archives/dita/201306/msg00058.html (PDF)
> https://lists.oasis-open.org/archives/dita/201306/msg00059.html (HTML)
> https://lists.oasis-open.org/archives/dita/201306/msg00060.html (Toolkit plugin, uploaded 17 June) 
> Eliot gave an overview; this will be a new specialization of @props to give a delivery target; his name for the new @ is @deliveryTarget, but he's not invested in that name. Then @print would be deprecated but still exist.
> - MarkM; we publish to various 'deliverymethods', e.g. 'instructor notes' and 'student notes'. Is this the same kind of thing?
> - Eliot; Not exactly, this is about delivery formats, e.g. PDF, HTML5, epub3, rather than types of content.
> - Kris; Eliot, you're suggesting that values be defined in a subject scheme map. That would mean we would possibly be shipping a non-normative subject scheme with 1.3. We don't usually do that kind of thing.
> - Robert; Actually, I think with 1.2, Erik Hennum proposed exactly that. He didn't put the materials together, so we didn't, but that was part of the plan.
> - Eliot; since the list of likely output types is pretty well known, it seems useful to suggest the way to use this.
> - Kris; This opens up issues about how we define this in the spec.
> - Eliot; My thought would be to do it as a completely non-normative appendix; not part of normative content.
> - Kris; We'll need to hash this out in the stage 3 proposal
> - Robert; Would values be mentioned in mormative part?
> - Eliot; I'd think we'd at least mention the most obvious ones, like PDF or HTML.
> - Robert; I think people would be looking for that, to see how this rlates to what they're already doing.
> - Eliot; For example, the subject scheme might have a top-level 'print' with subordinate forms like PDF, indesign, openofffice, etc.
> - Robert; Does anyone else have thoughts over whether to have recommended tokens rather than examples?
> Kris and MichaelP both expressed internal conflict about the need to provide more useful information to users, but without including specific non-normative content in the spec.
> - Robert; We want to have some recommended options, in that it would make it more likely that vendors would use the same names for the same outputs.
> - Eliot; As a counter to that perspective; this will be a normal select @, so you'd normally control it with a DITAVAL
> - Robert; I don't want users to have to set up a new DITAVAL rule, where they now just use @print="no"
> - Eliot; We'll need to consider that use case; currently it's not in the proposal.
> - Robert; if you set deliverytype="epub", then a processor needs to know not to include the topic when it goes to PDF.
> - Don; do we need synonyms for @s in a DITAVAL?
> - MichaelP: We may need to recommend high-level buckets like 'print', and then give a couple of examples - not recommendations - of lower level options.
> - Kris; Eliot, is that how your proposal works?
> - Eliot; Yes, but it doesn't give the same level of processing direction as MichaelP is suggesting.
> - Kris; This proposal will probably need a couple of adoption white papers to go with it.
> Resolution; TC will vote on proposal next week. 
> Proposal 13104: Enable keyref for and (Kimber)
> https://lists.oasis-open.org/archives/dita/201306/msg00074.html (DITA)
> https://lists.oasis-open.org/archives/dita/201306/msg00075.html (HTML)
> https://lists.oasis-open.org/archives/dita/201306/msg00076.html (PDF) 
> Eliot; currently, these are the only elements that can make references to resources using a URI that aren't keyref-enabled. They need to be updated to allow for keys.
> [not much comment] 
> - Robert; I wonder if there's not much response because no one uses 
> - MarkM; We use all the time.
> - Stan; We also use , and this proposal would be very useful; it would save a lot of copy/paste operations.
> - Don; The proposal notes that these were inherited directly from HTML, and don't partake of much DITA-ness. This is a way of fixing that.
> Resolution; discussion continued to next week.
> 3. DITA 1.3 proposals, stage 3: https://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage3
> Stage 3 review process: Responsibilities of proposal owner and reviewers
> https://lists.oasis-open.org/archives/dita/201306/msg00126.html (Eberlein) 
> Kris noted that for reviewers, it's important to look carefully at DTD changes in Stage 3 proposals, and think hard about changes to content models that may have unexpected impacts.
> Reviewers assigned - the following proposals had reviewers assigned (with thanks to those who volunteered):
> 13044: Extend content model of to allow %basic.ph rather than %words.cnt (Kimber; Reviewers: Magliery, Boses; reviewers assigned on 2 July)
> 13112: RelaxNG for DITA vocabulary (Owner: Kimber; Reviewers: Anderson, Hudson, Magliery; reviewers assigned on 25 June and 2 July)
> Additional Reviewers needed
> 13010: Add a element (Owner: Kimber; Reviewers: Buchholtz and TBD; reviewers assigned on 26 June & X)
> 13119: New domain for SVG support (Owner: Kimber; Reviewers: Bissantz and TBD; reviewers assigned on 25 June and X)
> In review:
> 13092: Allow within (Owner: Kimber; Reviewers: Doherty & Hackos; reviewers assigned on 26 June)
> 13116: Add to the content model of

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]