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

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


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

Hi Nancy,
 You forgot that we completed the discussion of 13114 and it is ready
for a vote next week.

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:
> Update on current deadlines:
> 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
> 2. DITA 1.3 proposals, stage 2:
> 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
> 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
> - 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
> - 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
> - 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:
> Stage 3 review process: Responsibilities of proposal owner and
> https://lists.oasis-open.org/archives/dita/201306/msg00126.html
> 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
> 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:

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