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,


The two proposals I *meant* to volunteer to review were 13010 and 13044.


In the minutes you have me down for 13112 (RelaxNG); I would not be useful as a reviewer for that one.






From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Nancy Harrison
Sent: Tuesday, July 02, 2013 10:59 AM
To: dita@lists.oasis-open.org
Subject: [dita] Groups - DITA TC Meeting Minutes 2 July 2013 uploaded


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.


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

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