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


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]