| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 19 February 2019 uploaded
- From: Nancy Harrison<firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 21 Feb 2019 06:08:39 +0000 (UTC)
1. Tom will schedule meeting to review Stan's suggested add'l examples for 2.0.
2. Kris will move non-normative formatting guidance to separate topics to illustrate Chris's suggestion.
Minutes of the OASIS DITA TC
Tuesday, 19 February 2019
Recorded by Nancy Harrison
link to agenda for this meeting:
Robert Anderson, Deb Bissantz, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois
1. Roll call
Regrets: Keith Schengili-Roberts
2. Approve minutes from previous business meeting:
05 February 2019:
https://lists.oasis-open.org/archives/dita/201902/msg00049.html (Harrison, 12 February 2019)
Moved by Kris, approved by TC
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
13 November 2018
Eliot: Test refactoring of grammar files
Spec editors incorporate changes from DITAweb review (Significant progress, very near to completion)
18 December 2018
Eliot: Investigate issue re earningAggregationsTopicrefConstraintMod.xsd
22 January 2019
Kris and Robert: Schedule meeting to plan moving forward on implementing complete DITA 2.0 proposals
29 January 2019:
Robert, Tom, Scott: Review examples that Stan suggests adding to DITA 2.0 spec
Kris: Set up regularly scheduled calls between DITA 2.0 and LwDITA spec editors
05 February 2019:
Kris: Add fix to 'xmlnamespace' topic to list of things to fix in 2.0.
12 February 2019
Tom: Schedule meeting to review Stan's suggested add'l examples for 2.0.
Kris: Move non-normative formatting guidance to separate topics to illustrate Chris's suggestion.
[no updates on any action items]
5. DITA 2.0 stage two proposals
#29: Rework bookmap design
Updated per 12 Feb discussion https://lists.oasis-open.org/archives/dita/201902/msg00052.html (Sirois, 19 February 2019)
Motion to move from Stage 2 to Stage 3: Eric - Second: Deb
Yes votes: 12 (Robert Anderson, Deb Bissantz, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Eric Sirois)
No votes: 0
Updates on committee note:
Summary of changes
https://lists.oasis-open.org/archives/dita/201901/msg00058.html (Eberlein, 31 Jan 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00061.html (Houser, 31 january 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00063.html (Chet Ensign, 31 January 2019)
PDF generated by updated stylesheets
https://lists.oasis-open.org/archives/dita/201902/msg00000.html (Eberlein, 01 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00006.html (Paul Knight, 04 Feb 2019)
Everything handled EXCEPT for font sizes for section titles on cover page, indentation for lists in body
HTML5 generated by updated stylesheets
https://lists.oasis-open.org/archives/dita/201902/msg00020.html (Eberlein, 05 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00028.html (Paul Knight, 05 February 2019)
Everything handled EXCEPT for:
Browser window title
Generating "Appendix" for the titles of rendered topics that are appendixes
Font sizes for section titles
- Kris: I've handled all of the changes required by OASIS with a few exceptions that require a more fundamental tweaking of code. Need more robust work on this over time. Need help from someone with more style sheet skills. Any volunteers?
- Eliot, Robert agreed to help with this.
***ActionItem: Kris, Robert and Eliot: Get together and have a meeting to plan out high-level changes to our Committee Note stylesheets.
Update on spec:
Re-branding requirements from OASIS:
https://lists.oasis-open.org/archives/dita/201901/msg00049.html (Forwarded by Eberlein, 28 January 2019)
- Kris: Spec, ony minimal tweaks made to fonts and colours. Some parts are completely broken. Alan and Tom had volunteered.
- Alan: Is there a timeframe in mind?
- Kris: Ideally it would be good to have support at all times. Right now we can't publish, period. (We prob could do a CN with some manual tweaks.) So priority is high. I'd like to have functional (if not perfect) style sheets that at least could run. Say within the next 30 days.
- Alan: I propose Tom and I work on this in the month of March, committed to being complete by DITA/NA.
- -Kris: Have you looked at the code for the spec plugins?
- Alan: Just a bit
- Kris: Think about whether you want to enlist Eliot and Robert about any high-level design. Some of the problem is that they've been written over time, added on, a lot of technical debt. To accommodate some OASIS changes, Bob added code that is fragile and breaking right now. Do reach out if you need any help.
- Alan: One of my goals is that since you and Eliot and Robert are generally overloaded, I'd like to bring myself up to be independent. I have done some XSLT training but this project will help me to start applying that.
- Kris: I'll make sure I've uploaded any changes I already made.
***ActionItem: Alan and Tom get working on having functional style sheets for DITA spec by time of DITA/NA.
7. New item: Reworked element reference topics
https://lists.oasis-open.org/archives/dita/201902/msg00053.html (Eberlein, 19 February 2019)
- Kris; I've removed 'Formatting Expectations' (FE) material from element ref topics and moved it into a single appendix; also changed sections titled 'Processing Expectations' (PE) to 'Rendering Expectations' (RE), and sent new stuff to TC list so folks could 'see' it.
- Alan; is the big picture purpose of this proof of concept? what would you like us to assess?
- Kris; we made a decision last week that we would 1) move FE stuff to non-normative appendices and 2) take FE guideline type stuff from the PE section, and then put it in a section called RE.
- Alan; how did we decide on 'rendering'?
- Kris; hard to know without minutes, but we made decision that PE was RFC stuff, but RE was that stuff that should occur because people have common experiences and should not be surprised. e.g. shortdesc should be rendered in text.
- Chris; PE has to do with anything a pre-processor has to do; RE has to do with broadest processing language about what processors should do about rendering content; FE has to do with style, fonts, subscript, etc.
- Alan; I like your description of how element shuold be rendered in ourput content, but I don't want it to be text or exclusively text. otoh, some REs like 'desc' could mention text, in a 'may' context.
- Chris; wrt desc element, for fig and table, it's a 'should'; for xref and linking, its a 'may'.
- Alan; it's content-centric.
- Kris; good to be reminded that there are many types of content that are not text-centric. Do you think we've adequately covered this item, or do we need to return to it?
- Alan; would like to continue to revisit this as we continue on LwD framework.
- Tom; will we have another review of these topics? I see, looking at 'desc', it doesn't mention 'object', which bothers me.
- Kris; wrt the review we had, only a few people participated, we should do it again, and have more folks participate, and have more definitions of what we think is appropriate content, and do we need more RFC statements?
- Tom; so another DITAWeb round?
- Alan; what are the boundaries of DITAWeb review? just the DITA elements that have LwD equivalents?
- Kris; yes
- Robert; if we manage to refactor other elements before the review starts, would be nice to include them, but otherwise what Kris said.
- Kris; if we add anything to this DITAWeb review, it should be @ content; that;'s where we'll need to do significant work.
8. New item: Proposed review of DITA 2.0 elements to LwDITA components
https://lists.oasis-open.org/archives/dita/201902/msg00042.html (Evia, 09 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00047.html (Eberlein, 12 February 2019)
[discussion below also has aplicability to agenda items #9-#13 and #15 listed below]
- Kris; I'm assuming this is in relationship to LwD ???
- Carlos; this was based on old PDF element descriptions for 2.0. we took elements that were in both DITA and LwD, and extracted PE/FE to see if they would translate to LwD without changes, or if they needed changes. In yesterday's LwD mtg, we decided not to do that until DITA TC is comfortable with it. We want to be as compatible as possible, or as much the same as possible. But I see a lot of stuff that will require conditional processing to remove XML terminology. So we want to see if TC agrees; we have a wiki page where we pasted all the elements and PE/FE/RE to see if they fly with LwD, or can be easily conditionalized, or if they need serious rework. Does TC think this is worthy experiment, and is this perception accurate?
- Eliot; so this is to see if we can be semantically identical, which is what I see as necessary.
- Carlos; we want to see what can be reused with new language, and what needs to be conditionalized with a new @props value.
- Kris; my assumption, like Eliot's, is that LwD must be compatible and interoperable with DITA. If so, we'll have to be very careful about having both specs be semantically, if not formally, identical, where they overlap. If we can't do well in conditional proessing, it's not a good sign for us as guardians of DITA.
- Alan; I've listed issues for the 'data' component. We strongly don't want to use term 'element' rather than component. We also have a subset of behaviors in LwD.
- Kris; So you seem to be mentioning 2 different issues:
1. you don't want to use term 'element'.
2. you think data functions differently.
- Alan; in LwD, 'data' isn't for specialization; it's a container for name/value pairs. It technically supports specialization, but for for reasons of adoption, we don't want to mention that.
- Kris; so it's not that it actually operates differently, but because of LwD audience, 'data' isn't intended used for specialization in LwD.
- Robert; in genral, it works the same, but it's severely constrained, and has a content model that isn't same as full DITA; so in the DITA spec we call out things that can't be mentioned for LwD.
- Kris; and so it may need a very different description than the one used for full DITA.
- Alan; that's our premise in a nutshell; many of these need different description or usage infomation.
- Kris; that's not surprising; we'll just have to be very careful that they're aligned; that an implemention of LwD should work in full DITA.
- Chris; to phrase it the other way; a full DITA implementation should be able to handle LwD without modification; otherwise it's not a subset.
- Alan; the LwD spec should be sufficient for guiding implementors; when XDITA is included, then the DITA 2.0 spec should define behaviors of DITA content. That helps me to understand how they don't need to be semantically identical, or at least not literally identical.
- Kris; you're teasing out areas where there needs to be very different usage info, like 'data', where the purpose of an LwD 'component' is very different from the corresponding element's use in DITA, where DITA is a superset of LwD.
- Alan; I'd say a significant superset.
- Kris; does it matter whether we say a superset or subset?
- Robert; no
- Nancy; and is one a 'proper' subset/superset of the other? In other words, will there be anything in LwD that isn't in DITA? Seems to me there shouldn't be...
- Alan; there are likely to be full DITA implementations that don't support LwD, in particular HDITA or MDITA. Conformance to LwD and to DITA are going to be 2 different things; implementors might do one or both. We envision having different implementations.
- Chris; the presence of HDITA and MDITA complicates the subset/superset question, but XDITA must be a proper subset of DITA.
- Eliot; so if you have a conforming LwD processor that only takes MDITA, and doesn't ever instanttiate XML, it would be conforming LwD processor but not a conforming DITA processor.
- Alan; I agree; there's no source format exchange expected or required; all source equally viable; no required conversion to XDITA and validation of XDITA.
- Eliot; conformance rules for DITA are very light, somewhat useless for requiring anything to be useful; e.g., if you have 'MUST' statements, you must do those things, but 99% of DITA is 'should' statements, which means it's mostly meaningless.
- Kris; wrt that, we barely managed to get 1.3 thru the OASIS TAB with our conformance; for 2.0 we have to do much better to get it thru TAB. We'll have to have RFC statements linked to conformance targets.
- Robert; based on what we expected 2.0 spec to look like.
- Kris; and the LwD spec will need to have equally rigorous conformance statements with conformance targets. The only way we got thru 1.3 was by arguing that we couldn't break backwards conpatibility, and we can't do that for 2.0 or LwD.
- Eliot; An unavoidable aspect of a standard like DITA is that conformance is tenuous; we can define it in terms of contents, but processors' conformance is much fuzzier; and LwD will be even more tenuous.
- Kris; I think we can make conformance statements around 'should' statements.
- Eliot; yes, but a processor can still conform even if it doesn't do the things the 'should' statements says it 'should', sine they're not 'must'.
- Kris; it's still important to use the 'should' statements, to give proccessors better guidelines, and make it easier for application conformance, though it's better than most OASIS specs.
[continued to next week. please read thru Carlos email. think we'll have to have an intensive side by side reworking of material. We still haven't addressed issue of 'element' vs 'component', or how LwD spec will handle @s.]
9. New item: Supporting LwDITA Implementors Quickly
https://lists.oasis-open.org/archives/dita/201902/msg00029.html (Kimber, 5 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00038.html (Houser, 7 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00039.html (Kimber, 7 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00040.html (Eberlein, 08 February 2019)
10. Re: [dita] Summary: Status of review of the DITA2.0/LwDITA intersection topics
What this thread covers Processing = Formatting; ph element in DITA and LwDITA; single-sourcing between LwDITA and DITA
https://lists.oasis-open.org/archives/dita/201901/msg00038.html (Houser, 26 January 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00039.html (Eberlein, 26 January 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00040.html (Houser, 26 January 2019)
11. Interoperability of DITA and LwDITA
https://lists.oasis-open.org/archives/dita/201901/msg00041.html (Eberlein, 26 January 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00042.html (Evia, 26 January 2019)
https://lists.oasis-open.org/archives/dita/201901/msg00043.html (Houser, 26 January 2019)
12. Misalignment example: LwDITA and DITA shortdesc topics
https://lists.oasis-open.org/archives/dita/201901/msg00044.html (Eberlein, 26 January 2019)
13. Lightweight DITA spec: development strategy
https://lists.oasis-open.org/archives/dita/201902/msg00001.html (Houser, 3 Feb 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00002.html (Eberlein, 3 Feb 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00003.html (Evia, 4 Feb 2019)
Attachment: Draft LwDITA spec https://lists.oasis-open.org/archives/dita/201902/msg00016.html (Eberlein, 4 Feb 2019)
15. October 2018 DITAweb review: Topics that exist in both DITA 2.0 and LwDITA
https://lists.oasis-open.org/archives/dita/201901/msg00036.html (Eberlein, 26 January 2019)
(UPDATED) https://lists.oasis-open.org/archives/dita/201901/msg00054.html (Eberlein, 29 January 2019)
11:58am ET close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]