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] DITA TC Meeting Minutes 15 January 2013 (text version)

Hi, Don.

One change to these minutes. In the discussion about product names and Michael's musing based on Troy's e-mail, I asked about writers who WERE monolingual English speakers. These are the folks who do not necessarily understand cases (and how they affect noun forms) ...

And yet again, thanks for taking the minutes and turning them around so swiftly!


Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
+1 919 682-2290; kriseberlein (skype)

On 1/15/2013 12:23 PM, Don R Day wrote:
In lieu of a sluggish Kavi system this morning, I submit this record:

Minutes, DITA Technical Committee, January 15 2013
Scribe: Don Day
Chaired by Kris Eberlein
Speakers during today's call:
    KE: Kris Eberlein
    RA: Robert Anderson
    DD: Don Day
    JH: JoAnn Hackos
    SD: Stan Doherty

Status of Tech Comm SC: (JoAnn)
    Had first meeting, Bob Thomas working on Stage 3 proposals with current template.
    Seth's team still on Release Management proposal. MP helping on the Steps domain for troubleshooting.
    MP asked about XML domain proposals. Kris has put this item on the agenda for today under stage 2.
    MP wanted feedback on whether TC SC would want that proposal to be part of one of their packages. Will discuss shortly.


No stage 1

Stage 2
13114 Adding @rev to <title> elements.
    JoAnn reviewed the user requests that motivated the need. Nothing new to add.
    Eliot added that his publishing users likely have the same requirement as well.
    Because title is required, it has no select-atts, so there is no reason @rev should not be allowed.
    RA: Likely an oversight due to original grouping of attributes.
    KE: Will queue this for a vote next week

13035 XML Mention:
    KE: is TechComm SC agreeable to add this item to their package (Eliot would still do all the drafting).
    KE: asked JoAnn to take an action to ask the SC about the request.
    Eliot reviewed the basics of the proposal for JoAnn.

Stage 3:
    None for discussion
    For vote:
    Proposal 13078: adding @rotate to entry and @orient to table
    JH: y
    RA: y
    MP: y
    AW: y
    MB: y
    SD: y
    DHe: y
    DD: y
    KE: y
    DB: y
    CN: y
    DHa: y
    EK: y
    TB: y
    Approved by acclamation of present voting members

New items: Difficulties mentioned on dita-users list with product names and reuse
    KE: reviewed the discussion on dita-users, referenced her note to the tc list
        * https://lists.oasis-open.org/archives/dita/201301/msg00010.html
    RA: reminded us of nesting keywords discussion, impact on domain specializations (element cloning in unintended places)
    DD: reviewed tension between schemas that mimic the programming model vs need to document parts of content within that markup.
    EK: keyword is pcdata or text or tm; are there any other elements that reuse keyword, and currently not (Robert's concern).
    RA: Robert would not change the keyword model
    EK: Wintitle does not allow tm, but could. Seems like an oversight
    RA: UIcontrol was motivated by output processing concerns (TM text should not appear in a UI)
    KE: Can already be abused; perhaps the question is whether wintitle could be specialized from ph instead of keyword.
    EK: Could break other's current work. Would have been ideal.
    KE: has been suggesting that others specialize their own wintitle from ph if needed.
        What people want to do is define their productname in an element. Adding tm to wintitle is a different issue.
    SD: Has a practice of using a glossary with ph, text, keyword to try to get all terms into one place for reuse--
        agrees with the general reuse problem.
    EK: there is a proposal to allow text where not currently allowed, might resolve part of the issue, but does not resolve
        reusable structures with semantic content (ie, product names with particular renditions)
    JH: Noted Troy K's response, intent to keep markup controls out of the source.
    KE: Notes that the management process is not available to smaller groups.
    MP: conref, conkeyref are all variable controls in DITA; Troy's approach is setting atts on the variable attribute
        to identify its usage in speech to aid translators.
    DD asked about glossary and part of speech, JH and MP both agree it is not sufficient as is.
    MP no mechanism in glossary for indicating same term in variant usage contexts.
    MP would explore the idea, though. Might be beyond 1.3.
    EK: Thinking of a general mechanism with glossary entry with forms of the term with a unique label for grammatic distinctions.
        Would use something like keyword to access the applicable part. Keyword with keyref would open up use of special phrases.
        System processing can be problematic.
    MP: Of all the ways to do it, let's start wiht the translation SC and capture it as a post1.3 requirement.
    KE: Appreciates MP bringing up case and other options. Would writer be responsible for indicating case?
        Is that okay for non-primary-English writers?
    MP: Writer just writes it; during translation, turn the variable file into an indexed lookup table that is actually
        managed by translators (those who have the linguistic domain knowledge).
    JH: affirmed that grad students can't generally diagram a sentence--it is a widespread concern.
    KE: outputclass is not available on text element--should this be considered?
    RA: explicit decision to keep it as just a pure text variable, with semantics added by other wrappers.
    KE: Another argument for not allowing tm in text.
    EK: Doesn't like tm, but RA countered with real IBM use cases  in support of legal business rules about rendering usage.
    RA: When contracts change, an external rules file takes care of changes in rendering rules.
    EK: trademark in text should be okay
    DD: recalled IBM's use of eServer's special e font--businesses CAN have a reason for supporting presentation in trademarks.
    KE: Not much of anything we can do for DITA 1.3
    EK: perhaps we can allow text wherever tm is allowed?
    RA: tm is in the basic group used everywhere it is explicitly allowed.
    EK: publishing needs more generality; that is an invalid reason in general.
    SD: If writers and archs are running into limitations--are there sensible practices to document? He'be willing to contribute.
    KE: Would be happy to work with Stan on that document.
        Appreciated the useful conversation, looking forward to what we might do with glossary.
    EK: be nice if tm were a specialization of text, but that's not possible.
    KE: Thanks all for the time, adjourned the call.

  • "Where is the wisdom we have lost in knowledge?
  • Where is the knowledge we have lost in information?"
  • --T.S. Eliot

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