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 16 October 2018 uploaded


Submitter's message
ActionItems: none recorded


=================================================
Minutes of the OASIS DITA TC
Tuesday, 16 October 2018
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, Maria Essig, Carlos Evia, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schengili-Roberts


Business
========
1. Roll call
Regrets: Eric Sirois


2. Approve minutes from previous business meeting:
02 October 2018:
https://lists.oasis-open.org/archives/dita/201810/msg00005.html (Harrison, 03 October 2018)
moved by Kris, 2nded by Scott, 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
no change
11 September 2018
Kris: Review conversation with Joe Pairman, e-mails about metadata, and TC discussion in late 2017/early 2018; summarize to TC
- Kris; no change
18 September 2018
Alan: Perform a test run in DITAweb to ensure everything works; handle any issues with Congility before 28 September 2018 (COMPLETED)
25 September 2018:
Eliot: Make a list of inconsistent file names in the grammar files
02 October 2018:
Kris: Make Robert's command-line actions for SourceTree equivalents available to TC (COMPLETED)
Kris: Open TC admin request to publish updated LwDITA committee note (COMPLETED)
Spec editors: Develop and document a plan for revision marking for DITA 2.0 spec
Unassigned: Look at committee note PDF and see if there are issues (look at minutes from 02 October 2018 for more information)


5. Subcommittee and liaison reports
None


6. Do we need to cancel TC meeting on 23 October?
TC members (voting and non-voting) who will be at Lavacon
https://lists.oasis-open.org/archives/dita/201810/msg00023.html (Eberlein, 09 October 2018)
TC gathering at Lavacon?
[after some discussion, TC made decision to cancel 23Oct call, based on a large number of TC members attending LavaCon during that time.]


7. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; Robert, how about the chunking proposal?
- Robert; think I will need to move it out by 2 weeks to Oct 30
- Kris; Eliot, how about your items due Nov 13th?
- Eliot; still on target.


8. DITA 2.0 specification reviews
DITAweb review of subset of element reference topics to open Tuesday, 16 October 2018
https://lists.oasis-open.org/archives/dita/201810/msg00026.html (Eberlein, 16 October 2018)
- Kris; the goals of this review are:
1. go over elements that coour in both LwD and regular DITA. Please read the PDF and compare with DITAWeb before you make your comments; DITAWeb sometimes messes things up, but the PDF will show what's actually there.
2. since we've moved contents into a new structure, especially look at contents wrt formatting/processing expectations; we thought about removing them, but the info has been there since 1.0 and users expect it.
3. are examples of high quality and appropriately introduced?
- Robert; formatting expectations has all been there before, but that doesn't mean it has to stay there in future.
Kris; we're moving all normative content into formatting/processing expectations
- Tom; just fyi, since we're conref'ing a lot of info, we want all normative statements to be independent enough to be pulled out of spec and put in an appendix while remaining comprehensible. Please check this in your review.
- Robert; so if a sentence seems a bit repetitive, that's why, to make it content independent.
- Robert; also, in DITAWeb, can click thru to @ topics; don't bother doing that; @ descriptions haven't been touched; if you look at PDF, those topics don't show up.
- Carlos; Alan and I want to clarify; review is for all topics, but in LwD, we're only reviewing shortdesc for topics, right?
- Kris; we also need to look at other opportunities for reuse, i.e. normative statements and processing expectations. We need to see if there are other parts that need to be reused.
- Carlos; OK; I've been putting in LwD examples that are fragments of topics. All LwD elements in the spec have full examples, not just stubs.
- Kris; we're just figuring out what needs to be identical in both specs, and what we need to do to make things work. So we want to hear people's thoughts and comments; we'll run review for 2 weeks.
- Keith; when this came thru as email, I was hoping for more context for what the purpose of this was.
- Kris; this is a review of element reference topics that will exist in both DITA and LwD; they're 2.0 topics, in 2.0 format,
- Keith; also, I have 2 other questions: first, elements appear to have different sections depending on element; what's the rationale?
- Kris; our intent is if an element is part of base, there's no point in having a specialization hierarchy section for it. All topics have title and shortdesc, but they'll only have other sections if there is content that is relevant.
- Robert; it's baesd on what was there in 1.3 and didn't seem out of bounds for 2.0, so if you see usage or formatting info that shouldn't be there, or missing usage info, comment on it.
- Keith; my other question is about examples; they're all rendered in XML, so there are no equivalents for XHTML or MDITA?
- Kris; these are for DITA 2.0, not LwD
- Robert; we will not be using full description within LwD spec
- Carlos; our goal in writing shortdescs is to have them apply to both LwD and standard DITA.
- Kris; that's the reason for using natural language, rather than an XML-centric approach. We expect processors to handle DITA and LwD in similar, if not identical, ways.


9. DITA 2.0 stage three proposals
Vote
Make @audience, @platform, @product, @otherprops into specializations
https://lists.oasis-open.org/archives/dita/201810/msg00001.html (Anderson, 01 October 2018)
Robert moved to approve this, 2nd by Bill
Voting results:
yes: 14: Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Kris Eberlein, Maria Essig, Carlos Evia, Nancy Harrison, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schengili-Roberts
no: 0
Initial discussion
None


10. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion
- Kris; Chris; do you need more reviewers for your proposal (#16 - Add titlealts elements to maps)?
- Chris; had one, still waiting for one more
- Chris; sent it out to Robert, Kris, bob, and one other person; heard back from reviewers, would love any more
- Chris; let me see if I can figure out who it was
- Bill; think I was on the ilst;
- Kris; just bring it back to list if you need any more,. BobT is out for awhile.
- Chris; for all the sturm and drang, I'm pretty happy with it
- Alan; I'll review it.

a. Strong and em elements
https://lists.oasis-open.org/archives/dita/201810/msg00012/strong_and_em_-_Stage_2_Proposal_%28Edited%29.pdf (Schengili-Roberts, 08 October 2018)
- Keith; I got feedback from Nancy & Bob; the proposal has been extended. One thing I'm not satisfied with is the domain name 'emphasis'. Previously, it was set up as 'semantic descriptors', which was more to the point, but more awkward. There was a suggestion to look at HTML equivalent - they use 'textlevel semantics' - but that includes italic and bold, which this will not.
- Kris; we do have the hasardstatement domain, which includes a hasardstatement element.
- Keith; a good point; I'm cool with keeping it, but it's the thing that's come up in every review. One significant addition was extending sets of examples for usage for each element in specific situations, including for old bold and italic elements.
- Kris; question or comments?
- Robert; I prefer 'emphasis' to semantic descriptior' domain.
- Eliot; 'semantic descriptor' as domain name gives me heebie jeebies...
- Alan; my issue is having a hard time accepting a brand new domain for 2 element types. We could provide all the elements if we put them in the typographic domain; it would be much less change and would be easy for users get their heads around.
- Kris; I have some sympathy for that.
- Robert; as we think about things in terms of RNG, rather than DTDs, it's easier to add domains, An I wonder if there would be confusion, having both trong/em and b/i in one domain.
- Keith; that was reason for keeping it out of highlighting domain in the first place.
- Kris; that brings up the point; I find more and more folks don't remove highlighting domain, but constrain it; would it make sense to make them into that domain and rename.
- Nancy; why change the domain name?
- Eliot; currently that's one level of indirection.
- Robert; everything in current highlightling domain has the same set of @s, but strong/em have a lot more.
- Kris; that begs question; what would we ship in 2.0 shells? both? only new one?
- Robert; we need to do both, otherwise people would be upset. What about using 'utilities' domain? what's in that?
- Kris; imagemap, sort-as
- Alan; that would be a statement in itself; the elements match highlighting domain much better than utilities.
- Robert; I'm inclined to keep it as a separate domain; otherwise we might have to add other stuff to this domain.
- Keith; in stage 3 draft, one thing that came to mind as a possible addition to this domain would be superscript, for use in semiconductor industry. Making things more specific to sectors that want to use specific elements. The point is that there could be additions to the domain for stuff that can be more easily semantically defined.
- Eliot; I would expect semiconductor folks to come up with their own specialization for something like that.
- Nancy; in fact, they did just that, when they designed the semicoonductor DTD.
- Kris; more questions? queue for vote? more discussion?
- Robert; we should go ahead with this thru gritted teeth; we'll end up with 2 pairs of elements to get somewhat the same purpose. But HTML has these, and people want to use the same tags as HTML. I think we should go forward with a vote.
- Kris; there are a lot of examples in the proposal; they'll need to be tweaked as part of stage 3.
[will vote next meeting]


11. DITA TC stylesheets for OASIS deliverables
New volunteer?
OASIS also has done some rebranding
- Kris; we need a new volunteer.
- Alan; I've done some very lightweight changes to get flagging, but my knowledge is definitely not at the depth of Bob's.
- Kris; so you have some potential, though not sure it's a good fit. Can you look at the spec stylesheets? Bob tried to do a lot in 1.3 that fell apart when we got to errata docs. Bob created some complexity that we've had to back out of. We want to ensure that people can generate output from our DITA source; we may need to get specific help from Eliot or Robert as well.
- Alan; do we have a backlog of what needs to be done?
- Kris; we don't have a formal list; that's one thing we need. We should be using github to track stylesheet issues. Alan, you and Carlos found issues in LWD spec.
- Alan; some of that was pilot error.
- Kris; so maybe there are fewer issues with CN, and most issues are with spec; I can populate github with issues I'm aware of.



12 noon ET close


-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 16 October 2018

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: 2018-10-25 11:32:48



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