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

Joann (and others),

The document loaded in the repository includes the record of the
discussion of 13114, and the fact that it's ready for a vote next
week.  And when I added it to the repository, I included in the
accompanying message all that information.  However, the message
forwarded by OASIS cut off the narrative in the middle, at the point
where the minutes include an opening angle bracket.  OTOH, if you
actually go to the OASIS repository and click on the link to the
minutes from there, the minutes in the repository are complete and
include all the content.

So, for this week, if you want to read the entire minutes, I'm afraid
you'll have to get them from the repository.  From now on, I'll avoid
including angle brackets in the copy I include in the email.


On Tue, Jul 2, 2013 at 2:53 PM, JoAnn Hackos
<joann.hackos@comtech-serv.com> wrote:
> Nancy What about 13114? It's ready for a vote next week.
> JoAnn
> JoAnn T. Hackos, PhD
> President
> Comtech Services Inc.
> 710 Kipling Street, Suite 400
> Denver, CO 80215
> Joann.hackos@comtech-serv.com
> 303-232-7586
> From: Nancy Harrison <nharrison@infobridge-solutions.com>
> Date: Tuesday, July 2, 2013 3:44 PM
> To: DITA TC <dita@lists.oasis-open.org>
> Subject: [dita] Groups - DITA TC Meeting Minutes 2 July 2013 uploaded
> Submitter's message
> [updated to correct reviewer list]
> 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
> - 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

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