dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 4 June 2019 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Thu, 6 Jun 2019 04:37:07 +0000 (UTC)
Submitter's message
[note; I have Stan listed as present and Alan listed as absent, but I'm not sure of either; please confirm or let me know if I'm wrong]
ActionItem:
1. Robert will check templates to see if they need to be fixed wrt mentioning updating shells as part of stage 2/3 proposals.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 4 June 2019
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Hancy Harrison, Eliot Kimber, Zoe Lawson, Tom Magliery, Chris Nitchie, Keith Schengili-Roberts, Jim Tivy
Business
========
1. Roll call
Regrets: Deb Bissantz, Scott Hudson
2. Approve minutes from previous business meeting:
28 May 2019
https://lists.oasis-open.org/archives/dita/201905/msg00063.html (Magliery, 31 May 2019)
(Adding attendance) https://lists.oasis-open.org/archives/dita/201906/msg00001.html (Eberlein, 04 June 2019)
Moved by Kris, 2nd by Bill, approved by TC
3. Announcements: none
4. Action items
[no updates to any items]
5. DITA 2.0 stage three proposals
Vote
None
Initial discussion
Add strong and em elements, and redefine b and i in a more semantic manner
https://lists.oasis-open.org/archives/dita/201905/msg00062.html
- Keith [see proposall for overview]. in add to strong and em, , also recast b and i, define them more fully than in 1.3 by saying when adn where they should be used; reviewed by bill and scott, very little changes from stage 2.
- Eliot; looking at the PDF version, the included example of emphasis domain on page 2 is mislabeled taskmod.rng.
- Keith; I'll fix that
- Dawn; on page 6 at the bottom, the last example should be b, has strong instead.
- Kris; As far as recommending changes like bold and italic, the proposal is referencing content from 1.3 spec rather than what we have in 2.0, which is very different.
- Keith; I was unaware of those changes.
- Kris; Robert; how do we handle that?
- Robert; the recomended changes just won't apply, because those topics have changed so much.
- Nancy; but we need to get a revised version out anyway, since there are also some corrections needed.
- Robert; agree
- Eliot; There's no indication in the proposal of how the shells will be modified, For migration. even though the shells aren't normative, we still reflect them in the spec., don't we?
- Kris; I can't remember whether our process includes changes to shells.
- Keith; there's nothing about it in the templates, and I followed the templates, so that may be a gap in the templates.
- Eliot; the proposal should at least state which shells are used by this domain. So there are 2 items to consider; 1) whether templates are correct, and 2) what Keith should put in this one.
***ActionItem: Robert will check templates to see if they need to be fixed.
- Kris; Keith, as you revise, please use the most recent template for element reference topics.
- Keith; I thought this was using the most recent.
- Kris; so we need to have the latest element ref topic loaded for the element ref template.
- Robert; the latest template is in stage 3 template.
- Kris; but we've made so many changes to that..
- Robert; the only thing out of date was changing 'formatting' to 'rendering', and I fixed that a few weeks ago.
- Robert; so, stage 3 proposal temoplate doesn't specifically state which shells are used, but it should fall into modified grammar sections, since shells are part of the grammar.
- Kris; also, we need to have a larger discussion for 2.0 on what we're doing with shells, what domains we include, and where and why...
[going back to current proposal]
- Eliot; both ref topics in last sentence in usage info have small grammatical issue. antecedent issue.
['addition of this element bring DITA more into alignment with its...' does 'its' refer to DITA, or to the element?]
- Keith; two sets of reviewers passed this, but I won't argue the point... Also, I hope Robert will be adding the shell portion.
- Robert; It shouldn't need to be modified. There's a section on modifying grammar files, and shells are part of the grammar files.
6. DITA 2.0 editorial work
Highlights?
See Editorial work completed for a full summary
See Backlog for open items and future plans
Working draft 04: https://lists.oasis-open.org/archives/dita/201906/msg00000.html
Addresses a few draft comments discussed on 28 May 2019
Reorg to some archSpec content to separate normative and (clearly) non-normative content
- Kris; Robert and I need to update our record of editorial work completed, but the key thing is that I uploaded a new working draft yesterday; in addition to incorporating comments, the update was to separate normative and clearly non-normative contents.
[much of following was from Zoom screen sharing]
- Kris; I moved a lot of non-normative content to 'Overview of DITA.' We need to review this very carefully, and to be very careful about not duplicating content; we had a lot of duplication in 1.3 between arch spec and langref topics. We kept the content in 'DITA markup' that seemed to be normative, it mostly had to do with subjectschemes, cascading maps, and file extensions. I don't think this is final, but it represents attempt to separate normative from non-normative content; non-normative and illustrative content is in Overview, while normative is in 'DITA markup', which is not the right title, but I wanted to move forward on this.
- Eliot; it seems like a good start; we'll have to look much more closely at it.
- Robert; I agree.
- Tom; I'll need to look at the content of the topics to get my head around it, but I like it. I think it should end up looking like the Overview section is shorter, and 'DITA markup' should be more detailed.
- Robert; it'a a bit misleading in that the 'DITA markup' section is just a small bit of what DITA markup is.
- Kris; the title should probably be 'this content should go elsewehre'; a lot of it is about map processing; in fact, a lot of the normative content in spec is about map processing.
- Tom; so a lot of content under the 'DITA markup' section will get relocated to other parts of the spec?
- Robert; we're not sure, they may need their own top-level sections.
- Kris; we have other major topics about addressing, that need to have a top-level section; e.g. there's a small section under navigation, and a lot of material about processing in element reference, that needs to be in this part of the spec. I think for 2.0, we don't want a separate arch spec and lang ref; we want element reference topics, but within one unified spec.
- Robert; regardless of whether you have something called an arch spec, that's what will be before the element reference topics.
- Nancy; so is the content going in both directions? i.e., content from element ref topics into architecture section, and vice versa?
- Robert; no, it's almost exclusively from element topics to arch material.
- Kris; we clearly need to have overview info in spec, but also need to make sure that it's clearly illustrated overview content, and we still have duplicate material that can get out of sync. So look at this content, read thru the Overview and what's in 'DITA markup', and see what you think.
- Eliot; 'DITA structure' may be ok instead of 'DITA markup;' and the XSLT spec might be a useful guide; it has the same problem of needing to separate things.
7. Draft comments in latest working draft from TC attention
We will review and discuss them, starting with page 230
Working draft 04: https://lists.oasis-open.org/archives/dita/201906/msg00000.html
- Kris; See how I've added draft comments to explain what I did; the next draft-comment provides more info about the DITA markup section.
look at pg 230 linkinfo;
- Eliot; the example is bad.
- Robert; this hasn't been looked at since DITA 1.0
- Kris; do we have any rendering expectations for this?
- Robert; just that it's expected to be rendered, which is the default for all elements.
- Kris; I'll remove processing expectations, but every link-related element needs to be reviewed.
- Tom; what are it's @s?
- Robert; @s aren't working or being rendered yet; should have univ-atts there.
[next draft-comment] still at linklist wrt rendering expectations
- Robert; this is the difference between linkpool and linklist; there's an expectation of order in linklist, while there's none in linkpool. But the way it's described is the wrong way around; we don't say, wrt 'ol', that it must be in order, that's implicit in its definition, so what we should say, rather than that there's an order in linklist, that in linkpool, there is no implicit order.
- Kris; so should we 1) remove this from the topic, 2) improve rendering expectations for linkpool, or 3) edit both?
- Robert; we should probably fix linkpool, that's the anomaly. we probably need a 'MAY' rule.
- Kris; Eliot, any thoughts on this?
- Eliot; I don't think we can say much; any link element can include a sort-of subelement, so processors ar free to order based on sort-as, which could be different from the authored order.
- Kris; so choice 1) is affected by sort-as. What do we, as spec authors, do in normative; do we make MUST statements?
- Eliot; isn't the intended semantic for linkpool implicitly unordered? That is, the author should have no assumptions about order. The opposite is true for linklist. I think you can get to this by making ordered/unordered distinction part of description of the elements. how you do the order is up to processor.
- Robert; I think it's right to say these are ordered; we just don't want to say that means you have to put numbers on them.
- Eliot; but this also doesn't preclude numbers.
- Tom; my suggestion; this usage information under linklist and linkpool is identical, could it better be under their parent topic, so removed from them?
- Robert; the container topics don't do that.
- Tom; but as an alternative suggestion, maybe the usage info for link should have that content.
- Kris; but this content hasn't been edited since almost 1.0, except to put it into the new template.
- Robert; and that is having the desired effect of having the wrong stuff show up.
- Tom; linkpool and linklist appear to have duplication.
- Robert; and the same thing holds true for index and index-see. So how do we handle that? It's a general issue.
- Kris; so editors need to do an editorial pass on link elements, then we need to review them. So, how many TC members have clients who use 'related-links.'
- Robert; I certainly do.
- Kris; I use them in the topics rather than maps, since a map would be overkill.
- Chris; I use them for refs to external information; when you need to have the link in the topic.
- Eliot; if you use inline xrefs, don't need links at all
- Tom; one common place for related-links, is in content that has been hastily converted to DITA, with the expectation that it would go to reltables, but where that never happened.
- Eliot; I haven't seen that, but most of my experience is in publishing industry documents.
- Kris; I haven't seen that very much.
- Zoe; I've seen it when converting a wiki; it ended up being a mess that we never cleaned up...
- Eliot; it hearkens back to early hypertext theory/practice.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]