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

["Tom Magliery" <tom.magliery@justsystems.com>]

Anyone else see the following strange behaviour regarding the emailed
minutes from Nancy? 

- When I read Nancy's message (in Outlook via Exchange), it is cut off
partway through. It is cut off at the phrase " Proposal 13104: Enable
keyref for", which looks like it would have been followed by markup. Do
we still have problems with markup? I thought those were solved.

- More mysterious: When I read JoAnn's followup message, I see MORE of
Nancy's message included, but it still looks as though the message is
cut off partway through. I've included what I see of JoAnn's message
here. Scroll to the bottom to see where it gets cut off -- again at what
looks like it would be markup. (You can also (not)see missing markup at
the same location in Nancy's text.)

mag



-----Original Message-----
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On
Behalf Of JoAnn Hackos
Sent: Tuesday, July 02, 2013 11:19 AM
To: Nancy Harrison
Cc: dita@lists.oasis-open.org
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.
JoAnn

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

---------------------------------------------------------------------
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