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 6 June 2017 uploaded

Submitter's message
1. Bob will look at Chet's latest mail on SC governance to review next week.

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

1. Roll call
Regrets: Tom Magliery, Chris Nitchie

2. Approve minutes from business meeting on 30 May 2017:
https://lists.oasis-open.org/archives/dita/201706/msg00013.html (Nancy Harrison, posted 6 June 2017)
moved by Kris, 2nded by Bob, approved by TC

3. Announcements:
New TC members: None

4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
04 April 2017
All TC members consider what they want to see on the new DITA.xml.org site for the DITA TC
09 May 2017
Eliot: Compare links provided by Paul Knight with those listed in the errata 02 documents at https://lists.oasis-open.org/archives/dita/201705/msg00036.html
Eliot; done
23 May 2017
Nancy and Alan: Review Adoption TC white paper: "DITA 1.3 A to Z"
Nancy; done, looked good, a few typos but only one substative question.
Alan; still in progress with an attempted re-org and re-casting of paper. Shall we mark this as a separate item to take up with Adoption TC?
Kris; I'd like the TC to be informed as well; we'll keep on the agenda for another week, we can mark the AI as complete, but want to take up Alan's re-org/re-casting with TC.
Kris; also, Nancy, please forward your comments to me and Robert.
30 May 2017
Robert: Errata 02: Wrong default version number in RNG
https://lists.oasis-open.org/archives/dita/201705/msg00080.html (Anderson, 26 May 2017)
Robert; done

5. Subcommittee governance
Current document: https://lists.oasis-open.org/archives/dita/201705/msg00051.html
https://lists.oasis-open.org/archives/dita/201705/msg00055.html (Chet Ensign, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00056.html (Eberlein, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00057.html (Chet Ensign, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00076.html (Chet Ensign, 25 May 2017)
Bob; not in a position to discuss right now
ActionItem: Bob will look at Chet's latest mail to review next week.

5. Lightweight DITA proposal
Committee note draft: https://www.oasis-open.org/committees/download.php/60914/LwDITA-v1.0-cn01-wd17.pdf
DTDs: https://www.oasis-open.org/committees/download.php/60915/org.oasis.xdita.zip
Overview of work for the TC: https://lists.oasis-open.org/archives/dita/201706/msg00015.html (Eberlein, 6 June 2017)

Kris; good work, need to look at these in 2 stages (not to be confused with formal proposal stages)
1. everyone needs to look at CN and grammar files from POV of a stage 2 proposal.
2) then look at it from POV of a CN for public consumption.
- Robert; we want to be careful calling it a stage 2 proposal; no way it could be considered one because it doesn't rise to that level of detail; somewhere between stage 1 and 2. Our review needs to give it level of attention of stage 2 proposal, but we know it doesn't have that level of detail; we'll need to note where it's missing stuff for later, but that stuff isn't appropriate for a CN.
- Kris; should this initial review to be to call out the details, so it can move closer to stage 2, so they can be added?
- Robert; but they shouldn't be added to the CN, since this is a CN, but need to call out the missing details; LwD is a new thing, not a change to something that's existing.
- Kris; I agree, but we do need to give it the kind of serious attention we would give a stage 2 proposal,
- Robert; this review should be a gut check; are we good with this design; no design points left hanging out.
- -Kris; and part 2), if we're ready to sign off of this, need to do a review of the CN as a CN, using DITAWeb. Then after that part 2) is complete, send it out for a 30-day public review, with DTDs, and get as much feedback as possible
Any comments?
- Alan; what's the mechanism for this discussion?
- Kris; for number 2, DITAWeb, for number 1, TC list?; for reviewing a CN, DITAWeb not so good.
- Robert; I think 1) needs to be the TC list
- Kris; yes, save DITAWeb for 2).
- Carlos; yes, we need as much review as possible.
- Kris; so timeline; how much time do we need for 1)? Can I get commitments from everyone on the call to look at CN and DTDs in next 2 weeks?
[gen'l agreement from TC]
- Kris; I will track comments to list and pester people... if we need to add time when points come up, we will do so. We will definitely need at least Robert, Chris, Eliot, & Bob to seriously scrutinize DTDs. and need comments as soon as possible.

6. LwDITA DTD/feature questions
https://lists.oasis-open.org/archives/dita/201706/msg00014.html (Anderson, forwarded by Eberlein, 6 June 2017)
Robert gave a long overview; This issue came up when Alan asked about @processing-role in LwD. The response was 'too complicated for LwD users, let's leave it out'. My initial reaction to that was "but I think it's needed for keydefs, but then if it's on keyref, doesn't it need to be on topicref?" My initial answer to that was "yes", but Michael said "no, we already have elements in LwD whese base element isn't included. specifically multimedia domain, where object isn't in it." So if we do that, can a user do that? The answer to that definitely needs to be 'no'... But Michael's response to that was "a user can't do that, but we, as the standard, can do that". I think that's a definsible position.
- Eliot; I agree with your final analysis; in case of video/audio, that's defined as a domain; in a constraint space, we can specialize an element and then constrain the base element out of your doc.likewise, constraints imposed on topicref/keyref, if they were defined carefully as constraints, that would be the case. Where folks may get confused, constraints are private to a shell and not only are types normative, but constraints we're imposing are normative as well.
- Robert; so all this that's been proposed for LwD are things you can do with constraints in a valid way, so we just don't want to talk about them.
- Eliot; still, I think there needs to be a companion spec? CN? ??? that says this is how you would define LwD formally as a valid application of DITA 1.3
- Kris; also, LwD grammar files aren't built in the way we specify in 1.3 spec. We need to doc that fact for users, and explain why and what the implications are. and how it could be done in a way that conformed to the 1.3 spec, but haven't, and why.
- Robert; I think it should be kept out of the spec. a separate note would be good, spec can note that it could be done, but not explain how.
- Kris; similar concerns/consensus about where this kind of info could go; it needs to be available, but not in spec and certainly not in the initial CN; should be in a companion piece.
- Robert; wherever that info goes, the detail in CN should be the same as of the eventual LwD spec, so it shouldn't be there.
- Eliot; I think it needs to be somewhere, but not in CN or LwD spec
- Kris; needs to be somewhere so TC members can look at it and understand how LwD is the same as, and is different from, regular DITA, so as to understand interchangeability issues.
- Bob; so you can understand the path and how it was derived from 1.3.
- Robert; in LwD, you don't have to show the path, but it still needs to be there. We're saying; here are the LwD rules, follow them and you're good; but even in in regular DITA, there was a way to get here...
- Kris; I'd like to have a good understanding of all the LwD things that don't meet the 1.3 rules.
- Robert; in DITA, to specialize, you have to be able to point back to the base; for LwD, you have to be able to point back to original LwD.
- Alan; my understanding is that LwD does not have to be a formal specialization of 1.3, but understanding how it points back to 1.3 would be a good thing.
- Carlos; the DTDs were started before there was a 1.3, and we've been building on top of those, but no one has incorporated best practices from 1.3.
- Kris; we can incorporate the changes between 1.2 and 1.3. the main thing that changed was an ability to re-use a structural specialization. We also need to scrutinize the LwD DTDs and send them out with the CN to the public.
- Kris; for TC members who are not individual OASIS members, if you could get others from your companies to review the LwD draft, that would be great, e.g., Leigh.

8. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
Style sheets: Progress?
New item: None

9. New DITA 2.0 stage one proposals
Remove deprecated and "reserved for future use" items
https://lists.oasis-open.org/archives/dita/201706/msg00016.html (Eberlein, 6 June 2017)
- Kris; we've always assumed we'd do this, but never queued up as a proposal, but it needs to be one. most of these don't have any usability hits, but need to look at navtitle; could affect every dita map in existence
- Eliot; I hope not..
- Kris; many people use navtitle as authoring convenience in a ditamap.
[Eliot, somewhat sotto voce, 'and they shouldn't do that..']
- Robert; i disagree with that; still in huge use in IBM despite have the other thing available. Authors haven't seen any problem
- Eliot; shouldn't allow people to have diff titles from navtitles
- Kris; depending on folks authoring env, actual only way to see what a topic is about may be that, esp if an href/keyref is pointing to a GUID in a CCMS, very -useful.
- Eliot; feel very strongly that @navtitle (attribute) should be removed, very problematical for localization.
[gen'l concurrence to remove @]
- Stan; we've marked it as deprecated for a long time; even the tools vendors should have had time to adjust
- Kris; anyone besides me and Robert who sees issues with removing it?
[no one]
- Kris; so we should move this to stage 2.
[moved by Kris, 2nded by Bob, moved to stage 2]
- Dawn; question wrt L&T, for simplicity, we want to remove all the old stuff, but we'd want to go back to the old non-2 names; given the way things are being done for removing deprecated items in 2.0, how shall we handle that?
- Kris; since we're going to separate L&T from base at 2.0, that would be something for you to discuss in the L&T SC.

9. DITA 2.0: Review of stage one (in progress) cards
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
Deprecate type="fastpath" attribute value for note elements (Magliery)
[hold for when to is here]
Remove the locktitle attribute from topichead and topicgroup (Anderson)
- Robert; I think this is a good idea; @locktitle makes no sense there.
- Kris; does this need a proposal, or is it a bugfix?
- Robert; technically it's backwards incompatible, so it needs a proposal
- Eliot; could they have been auto-generated? If so, migration could be a bit of work.
- Robert; there was no default value, so probably not.
- Eliot; does it make sense to have a formal proposal?
- Kris; we could fold this into the above 'removed / deprecated elements' item.
- Bob; really a housekeeping item
- Kris; we can name the proposal 'technically incompatible housekeeping' :-)
FROM BACKLOG: Allow domains to add elements to a specific context, rather than globally. Can this easily be done in RNG? Should be part of broad DTD / RNG / XSD changes?
[hold to next week]

11:57am ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 6 June 2017

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: 2017-06-06 15:29:15

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