[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
I'll avoid angle brackets in the 'submitter's note' - the part that gets included in the email announcing the minutes - when I submit future minutes; nonetheless, if you click on the link to the minutes from the TC 'documents' area, the entire minutes are displayed, including the [angle-bracketed] element names for 13104 and the description of our discussion of 13114 (@rev on title elements). Nancy On Tue, Jul 2, 2013 at 3:14 PM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote: > Kavi cannot deal with angle brackets :( > > Best, > Kris > > Kristen James Eberlein > Principal consultant, Eberlein Consulting > Co-chair, OASIS DITA Technical Committee > Charter member, OASIS DITA Adoption Committee > www.eberleinconsulting.com > +1 919 682-2290; kriseberlein (skype) > > > On 7/2/2013 5:46 PM, Nancy Harrison wrote: >> >> 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 >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- _____________ Nancy Harrison Infobridge Solutions nharrison@infobridge-solutions.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]