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

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

I've just updated the minutes to fix the reviewer lists.  thanks, Tom
for noticing the weirdness (btw, the item on @ref with <title> is in
the document, even if it hadn't appeared in the mail.)

Nancy

On Tue, Jul 2, 2013 at 12:51 PM, Tom Magliery
<tom.magliery@justsystems.com> wrote:
> 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.
>
>
>
> mag
>
>
>
>
>
>
>
> 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.
>
>
> 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



-- 
_____________
Nancy Harrison
Infobridge Solutions
nharrison@infobridge-solutions.com