| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 30 January 2018 uploaded
- From: Nancy Harrison<firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 30 Jan 2018 13:05:06 -0800 (PST)
1. All TC members who committed to completing a stage 2 proposal by end of January need to have them complete by next TC meeting on 6 Feb.
Minutes of the OASIS DITA TC
Tuesday, 30 January 2018
Recorded by Nancy Harrison
link to agenda for this meeting:
[meeting chaired by Tom; Kris has the flu]
Robert Anderson, Deb Bissantz, Bill Burns, Stan Doherty, Nancy Harrison, Alan Hauser, Eliot Kimber, Tom Magliery, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Maria Essig, Joe Storbeck, Amber Swope, Jim Tivy
1. Roll call
Regrets: Carsten Brennecke, Kris Eberlein, Joe Pairman, Bob Thomas, Carlos Evia, Scott Hudson, Chris Nitchie
2. Approve minutes from previous business meeting:
23 January 2007:
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/62387/minutes20180123.txt (Nancy Harrison, 24 January 2018)
moved by Tom, 2nd by Eric, approved by TC
3. Corrections to approved minutes
Typo in minutes from 14 November 2017
https://lists.oasis-open.org/archives/dita/201801/msg00049.html (Magliery, 22 Jan 2018)
Approval of minutes w/typo
Nancy has corrected 14 Nov minutes and changed status to 'approved'
New TC members: None
Welcome Deb Bissantz (Vasont Systems) back to the TC as a voting member
5. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
19 September 2017:
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
05 December 2017:
Robert: Investigate issues that OASIS found re HTML generated by DITA-OT (IN PROGRESS)
- Robert; fixed
09 January 2018:
Chris: E-mail about adding new vocabulary element for inclusion of external XML; confer with Robert and Eliot (IN PROGRESS)
[Chris not on call]]
16 January 2018
Eliot: Stage one proposal about new topic type in which title is not important/not rendered
eliot; this is done
23 January 2018
Kris: Request 15-day public review for DITA 1.3 Errata 02
Kris: Request OASIS publish "LwDITA: An Introduction" committee note
[Kris not on call]
6. "LwDITA: An Introduction" committee note: Items from public review
- Tom; Carlos had sent email to SC to alert them to changes needing to be made.
- Alan; right, we discovered after approval that the keys @ was omitted from the list of @s, as well as from at least one example. This would be a substantive change, so we're planning to put the CN thru another approval process to start another 15-day review.
7. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
- Tom; Bob created .chm files for Errata02
- Nancy; and Kris tried to get OASIS to set up a public review, but I saw her email about admin issues with OASIS.
- Tom; I saw those also.
- Nancy; I think it's probably not in the pipeline yet.
- Tom; I agree.
8. DITA 2.0 stage one proposals: Discussion
a. RDFa support
Summary by Keith Schengili-Roberts: https://lists.oasis-open.org/archives/dita/201801/msg00047.html (22 January 2018)
(Slight) correction by Eliot Kimber: https://lists.oasis-open.org/archives/dita/201801/msg00048.html (22 January 2018)
Comment by Joe Pairman: https://lists.oasis-open.org/archives/dita/201801/msg00057.html (22 January 2018)
[hold till JoeP is on the call]
b. Redesign of Image to Include Metadata
https://lists.oasis-open.org/archives/dita/201801/msg00061.html (Kimber, 23 January 2018)
- Tom; I looked at Eliot's idea in his email, but he already has as many stage 2/3 proposals as he's allowed.
- Robert; no, the limit is for stage 2 and 3, not 1.
- Eliot gave an overview]
The proposal covers 2 main parts.
1. satisfy the requirement to have metadata directly contained within image,
2. create an element (that will be a child of image) that does nothing but reference the image, which makes using an image more flexible.
I took the existing image element and modified the content model to add an 'imageref' child with @s href, keyref, etc. to serve as a reference to the graphic format. Then I added a new 'imagelabel' child (specialization of data) to allow a descriptive label for image; this would be purely metadata, so useful for a CMS.
Since we'd now be allowing data elements within image, we could also include a specialization of data (imagelabel). By separating the reference to the graphic from the image as a whole, it allows it to have various renderings, (e.g., hi-res/lo-res/tiff/png etc.)
- Alan; Is imageref allowed without image wrapper?
- Eliot; no, it's only inside image element,
- Alan; so, is it possible to reference a graphic from outside an image?
- Eliot; if we agree that a reorg of image is what we want for 2.0, then we still have the option to have the reference @s that we had in 1.3. But we've extablished that we want to have only one way.
- Nancy; so will this be a new element, or are we redefining image so everyone will have to migrate?
- Eliot; everyone would have to migrate to the new image.
- Robert; I'm very conflicted... This addresses one of my primary frustrations, i.e., moving into new publishing systems. and managing mul;tiple rendering. But while we're allowing backwards incompatible changes in 2.0, we're trying to make it worth migrating to. This would hit absolutely everyone, and make things more complex for the general case.
- Dawn; I agree with Robert. I'm thinking about users who put their images inside a fig element. They would end up with a fig, containing an image, containing an imageref.
- Eliot; but that assumes you're using fig...
- Robert; but that's a very common case.
- Eliot; I wouldn't object to having image allow a direct imageref to itself as well as including imageref.
- Robert; I don't know if we'd consider one of those primary; I'd prefer the current usage to be primary.
- Eliot; I think we'd have to set it so that if you don't have a ref from image at all, then if there were only imageref subelements, then the rule is that the first imageref is primary.
- Robert; I could agree with that.
- Nancy; ignoring migration issues, that's cleaner, but I don't think we can ignore migration issues so completely.
- Eliot; once you have an alt element, it doesn't change amount of markup you have.
- Robert; true, but for the common case, it's just an extra element, not an extra level of nesting. People are used to a reference to an image within the image.
[discussion of HTML issues and origins of image tag.]
- Robert; there are several aspects to this proposal; the part about adding metadata is fine; adding an extra label, I'm not sure about. we don't currently have a base element that contains a specialization.
- Eliot; we could put it in techcomm...
- Robert; but then we wouldn't have image in DITA base, where it is now.
- Eliot; if we leave base image as itself, then techcomm could constrain image to allow the data specialization as a first child of image.
- Robert; that feels vaguely uncomfortable to me, especially if we're thinking of it as something for CMSs.
- Eliot; we don't currently have a specialization for ??
- Amber; the fact that the usable base of DITA is really techcomm is a real issue for people wanting to go to DITA for non-techcomm uses.
- Eliot; what about a layer of specialization between base and techcomm that provides useful stuff in base.
- Robert; if it's useful enough to go into everything, maybe it should go in base. REally, imagelabel as a specialization of data is the problem, we should have imagelabel as a base element.
- Tom; so that would be a new stage 1 proposal. There are a couple of things to talk about, modifying substructure, and new imagelable.
- Robert; I'm adding a card as we speak for this proposal to our project list; it will be waiting for someone to take it on.
- Tom; is it allowed for someone else to take over one of Eliot's other proposals so he could work on this?
- Robert; yes.
c. "Titleless" Topics and Context-Independent Content
https://lists.oasis-open.org/archives/dita/201801/msg00056.html (Kimber, 23 January 2018)
- Eliot; the goal here is to let a processor know that for a given topic, the title is not important and should not be rendered in normal output; content should be rendered as though it's just the child of the topic's parent. This is especially for Q&A. so it's 1) a specialized topic type which says it's title (if it has one) isn't imaportant, and 2) a topicref specialization, wihch references a topic without caring about its title, if it has one. It would be either a property of the topic, or a property of the topicref.
- Tom; do you have proposed names for either new element?
- Eliot; not yet
- Tom; comments?
- Maria; I think this is great; we do a workaround to achieve the same effect.
- Tom; there will be issues with edge cases.
- Robert; If you have a topic used in one case with a title and in another case without, it will be interesting to see when people make errors in referencing.
- Robert; I'm not sure about the referencing topic.
- Eliot; I'm thinking of legacy issues. at this point there are at least 4 consultants who've defined our own versions of this;
- Robert; I understand your perspective, but we have utility elements in DITA that we put in for just that reason, that we now want to get rid of.
- Eliot; If others agree with Robert, I'd agree to remove the specialized reference, and just leave the specialized topic design.
- Tom; we can keep the proposal, as long as we include this issue as a part of the propodal itself, so it will come up in discussion.
- Robert; I'm making up a card for this proposal.
- Tom; so it's in the same state as previous proposal; a stage 1 proposal made by Eliot, that can't go forward to stage 2 until/unless someone besides Eliot is willing to take it on.
9. DITA 2.0 stage two proposals
Review of of proposed dates for stage 2 proposals in progress
Delayed conref domain:
https://lists.oasis-open.org/archives/dita/201801/msg00044.html (Houser, 21 Jan 2018)
Alan gave an overview; the stage 2 prop isn't finished, but in preparing to delete this, I had the impression that it was kind of a cool feature, so do we really want to get rid of it? The feature lets some ocnrefs be resolved at rendering time, post-transformation.
- Tom; who was author of this proposal
- Robert; I was; we added this feature at 1.1, and afaik, no one has ever used it successfully. In fact, afaik, it can't be used outside of the Eclipse platform. and even for Eclipse, the current design is really hard to use; I can't imagine mainitaining the markup in a way that makes it useful.
- Alan; someone said there's other ways to do this; can someone explain?
- Tom; does this satisfy your concern about removing the item?
- Alan; yes
- Robert; if someone came up with a way to use this successfully, they could do it on their own. In 1.1, this was added purely for Eclipse.
- Alan; there's a note in the spec saying that most publishing systems won't support this. But I just wanted to confirm that people involved with the original feature agree that it should be removed.
- Robert; even in IBM, no one is using it..
- Alan; OK, I'm satisfied; I'll continue with the stage 2 proposal.
- Keith; it seems to have fallen off the agenda; what about multimedia domain?
- Tom; we don't have Chris Nitchie, that proposal's champion, here, but I'll remind Kris and Chris about it.
- Robert; also, there are some proposals that were originally scheduled to be ready by the end of January - this week - but with Kris's absence, they get a break. They need to be ready by next week's meeting, just in case you have one of them.
11:59 am ET close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]