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: Groups - DITA TC Meeting Minutes 8 January 2019 uploaded

Submitter's message
1. Chris will update titlealts proposal to include discussion from last meeting

Minutes of the OASIS DITA TC
Tuesday, 8 January 2019
Recorded by Nancy Harrison
link to agenda for this meeting:

Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Nancy Harrison, Alan Houser, Eliot Kimber, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens, Amber Swope

1. Roll call
Regrets: Tom Magliery, Carlos Evia, Scott Hudson, Carsten Brennecke

2. Approve minutes from previous business meeting:
18 December 2018:
https://lists.oasis-open.org/archives/dita/201812/msg00023.html (Harrison, 18 December 2018)
moved by Kris, 2nd by Deb, approved by TC

3. Announcements:
New TC members: None

4. Action items
21 August 2018
Kris & Robert: Perform the best edit of multimedia topics that they can do in time available; due 18 September
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC
30 October 2018:
Kris: Open GitHub issue for committee note PDF issue regarding formatting (some URLs are not blue) on coverpage
13 November 2018
Eliot: Test refactoring of grammar files
Spec editors incorporate changes from DITAweb review
[no change to items from Aug - Nov]
18 December
Eliot: Investigate issue re: earningAggregationsTopicrefConstraintMod.xsd
- Eliot; I did look at learninconstraint.mod; looks like it should be there; need to spend a bit more time on it.
Kris: Respond to e-mail from Wolf-Dieter Wurst on dita-comment
[no change]

5. Review of DITA 2.0 proposal deadlines
- Kris; Robert, any movement on chunking?
- Robert; I'm still waiting for Eliot's review
- Kris; Eliot, would it be better to get a substitute for the chunking proposal?
- Eliot; no, I can do it
- Kris; well, please push those forwards if you can; do you need a reviewer for copy-to?
- Eliot; I'm still working on it; I've been thinking about it but haven't come to conclusion about addressing reqs...

6. DITA 2.0 stage two proposals
Continuing discussion
Issue 16: titlealts improvements
https://lists.oasis-open.org/archives/dita/201812/msg00016.html (Nitchie, 17 December 2018)
Chris; don't have a lot to add to the proposal; l just wanted folks to get a good chance to review it; I've created a new titlealt element to go inside titlealts; navtitle/searchtitle elements will be modified to be specializations of titlealt instead of being their own elements; it does break navtitle w/in a map. In the new proposal, we remove @locktitle, so navtitle means navtitle. It will likely cause breakage in existing maps, if you don't remove effectivity in navtitle; proposal suggests migrating to navtitle/@titlerole="Hint". It will be easier and more intuitive for new DITA users, but some migration for current users because of navtitle/@locktitle
- Kris; does the new ersion also make moving from @navtitle to 'navtitle' element a bit more dificult?
- Chris; there's some migration required, but it's not complicated; it's just looking for presence of @locktitle. then the migration process should create a @titlerole appropriate to intended use of navtitle, often "hint'.
- Kris; will we be defining a set of possible @s for @titlerole
- Chris; no, we won't.
- Eliot; I had a req exactly like the bookmap example; a title to be used in PDF bookmarks; on discussion of tokens, might be good to codify 'hint' as well as searchtitle and navtitle.
- Chris; I'd be OK with that; would it be as a general purpose token; as a reserved token, or a specialization element?
- Eliot; just a reserved token.
- Chris; we have a new domain, so there's a place to put it.
- Robert; I also think a reserved token would be good, but I'm not sure of value of adding a new element, people always complain about it when we add new elements (unless of course it's one they asked for...)
- Chris; maybe for purposes of migration, an element might look a bit cleaner.
- Kris; but do we really need a titlehint element? More and more tools automatically retrieve titles, so we don't really need the markup and behavior we did earlier.
- Chris; just making sure we consider all options.
- Kris; so we have 2 possibiliities; is there a preference?
- Eliot; I'm happy with just the keyword.
- Kris; just specify hinttitle to go with searchtitle and navtitle.
[Chris will update proposal to add this discussion; TC will vote on this next week]

Initial discussion
Issue 98: Titleless topics
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/64497/latest/Titleless_topics_stage2.html (Stevens, 07 January 2019)
Dawn; stage 2 reviewers haven't had a chance to review this version. There's a long history for this; in current proposal, author can just put a filter on title to have it excluded from processing. Req came from L&T where this is needed, and adding the filtering capacity allows also for selecting from multiple titles, but I didn't focus on that aspect.
- Amber; we originally came up with this for L&T, but it turns out that in working on standards topics, they need it as well, so I think we'll discover ever more use cases.
- Kris; Dawn, who are your reviewers?
- Dawn; Stan, others?
- Kris; we need to have review complete before we can consider a vote.
- Stan; I can look at this this week.
- Robert; I can as well.
- Kris; any comments?
- Eliot; I'm still thinking thru implications; this will have impact on implementors of DITA processors, because it changes fundamental rules of 'topic always has title', and here, it will already have been filtered away
- Kris; and anyone whose processing depends on getting normalized content; their content will no longer be valid.
- Chris; also will create issues with empty xrefs
- Robert; I see two issues:
1. implementors will need to be aware these things can happen; so more checks are needed;
2. for users, if you're depending on normalized output, you can have problems.
- Chris; but this is a presentational concern; topic has a title, just isn't displayed.
- Eliot; that's my sense of it.
- Chris; so it's really a stylesheet concern.
- Kris; I'm having a bit of fundamental problem with allowing a topic w/o a title
- Eliot; gets to question of where you apply your filtering, could be at the end, which makes it a presentation thing, but most do it earlier.
- Kris; also, part of 2.0 is mandating a processing order...
- Eliot; it gets really compicated... appropriate processing order mandate would be that, while titles can be filtered out, they can't be filtered out till end of processing.
- Chris; but it's just presentation; topic still has a title, it just doesn't get presented...
- Robert; original proposal introduced a new way that every author would have to consider wrt filtering; authors would have had to learn a new way of filtering just for titles; that's makes me uncomfortable
- Eliot; largely agree with Robert; if we go with filtering on titles. what is implication of where filtering is done as literal transform, not just as a presentation?
- Kris; also makes me wonder; if we go with enabling filtering on titles, what effects on CMSs that don't support specialization on conditional processing?
- Robert; they generally do it in a proprietary way, and ignore our restriction on titles.
- Kris; no, they don't always do that.
- Robert; if they're already not in sync with us, they can do one more proprietary thing...
- Kris; so, where do we want to go with this propoasal? we've raised some questions and concerns with it.
- Chris; I have a proposal about simplifying @ specialization rules. one is ability to define a @ specialization for just a specific element. Once we have that, it might make more sense to suggest that the L&T profile create that kind of specialization for titles, so it wouldn't be a general specialization for them in the base.
- Kris; but Amber says there a more general need...
- Robert; also, you can only create a specialization on an element if the original @ (i.e. @props) was there on the base element.
- Chris; but we could do a base specialization. it's a presentational thing, could be a stylesheet switch
- Kris; if we don't make it available in all of our doc shells, but only in some, that wouldn't be used like a traditional filtering @.
- Robert; but it doesn't address one of the use cases; these are topics where the title is rendered in some use cases but not others; so you need all your regular filtering logic.
- Chris; only if all the stylesheets use the switch... for an implementor , that's not that hard.
- Robert; not hard, provided you know your tokens and what you're working with. It's harder if this is a standard feature; to have a generic @ that's intended to meet those needs, you end up with our filtering @ today, and processor has to deal with all of them.
- Kris; minutes will help us talk about this.

7. DITA 2.0 stage three proposals
Continuing discussion
Initial discussion
Issue 08: New include element
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/64447/latest/Issue08-stage3-include.html (Nitchie, 18 December 2018)
Chris; this is a new base vocab element called 'include' modeled on XInclude standard, with same subelements. 'fallback' element is part of media domain in base DITA, Rules are that; if you use parse=XML", must appear inside a 'foreign'; otherwise should be parse="text" or parse=[URI] to allow tools to support inclusion of other formatted objects (e.g. in Markdown)., BUT the formatting of other formats won't be built into standard DITA. Referencing semantics same as xref, but to include rather than reference the target.
- Kris; any questions or comments?
- Alan; if I want block type behavior, do I put this within a 'p' with foreign child, or 'fig', or what?
- Chris; if you're including foreign DITA content; use conref. This isn't meant for transcluding DITA content; it's meant for foreign content. If you want, you can render an XML schema doc, If you want to bring in Markdown content and render it as DITA, you'd probably put it in a section.
- Eliot; Chris and I had a lot of discussion on this; I do object to allowing a reference to data that's not marked up in DITA to be rendered in DITA; I think it should be done from within conref. However, I agree not to object to this proposal, even though it opens up a huge 'back door'. I want the base that can be used for needed formatting.
- Robert; I read it and commented on it, but my comments were all cosmetic...
- Chris; I did make some changes based on comments.
- Kris; we'll queue up for vote at next TC mtg.

- Kris; any announcements or items for next week's agenda? At last mtg, Carlos announced his LwD book, I meant to add an update from Adoption TC?
- Stan; next week?
- Kris; OK

12 noon ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 8 January 2019

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2019-01-14 20:29:26

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