Groups - DITA TC Meeting Minutes 8 January 2019 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItem:
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:	
https://wiki.OASIS-open.org/dita/PreviousAgendas


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


Business
========
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
        https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 
- 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
        Vote
            None
        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
        Vote
            None 
        Continuing discussion
            None 
        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.

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