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 21 March 2017 uploaded


Submitter's message
ActionItems:
1. Chris will send mail to TC about his proposal for re-designing bookmap such that it wouldn't break existing docs, by making frontmatter and backmatter optional, and allowing topicref at the root level.
2. Kris will post to L&T SC, as well as general TC memmmmmmmmbership and dita-users, with summary of our discussion today, including a note that SC members have to be OASIS members. She will also touch base with Dawn and Amber, who have L&T-using clients.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 21 March 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas



Business
========
1. Roll call
Regrets: Carsten Brennecke, Dawn Stevens


2. Approve minutes from business meeting on 7 March 2017:
https://lists.oasis-open.org/archives/dita/201703/msg00020.html (Nancy Harrison, posted 14 March 2017)
moved by Kris, seconded by Dick, approved by TC


3. Announcements:
New TC members: None


4. Action items
23 August 2016:
Kris: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN (IN PROGRESS)
Kris; working with Congility; I tested that their sandbox works with 1.3 and syncs with SVN; we just have to confirm that it's working not only in the sandbox but in real SVN version.
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)
25 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
21 February 2017
Kris: find someone from the iiRDS working group to come to TC meeting and do presentation. (IN PROGRESS -- Tentatively scheduled for either 18 April or 02 May 2017)
Kris; have talked to a couple of folks about coming to a meeting; scheduled for 4/18 TC meeting.
Kris: Organize meeting with Robert, Kris, Dick, and Dawn about workflow/admin practices for DITA 1.3 errata 02. (COMPLETED -- Scheduled for Thursday, 23 March at 3 PM ET)
28 February 2017
Robert: update 2.0 proposal process to include info on removing something from a shell without removing it from the specification.
Robert: update 2.0 proposal process to include info on referencing deprecated elements/attributes, in case of backwards compatibility issues.
Robert; both of these items are done.
07 March 2017:
Robert: Update DITA 2.0 process to include link to instructions for stage 3 reviewers / reinforce idea that reviewers need to validate proposals
Kris: Organize meeting with Dawn, Carlos, Robert, Nancy, and Chris to discuss high-level design for DITA 2.0 spec. (COMPLETED -- Scheduled for Wednesday, 22 March at 3 PM ET)


5. Continuing item: DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
[update next week]


6. Continuing item: Overall fixes for bookmap for DITA 2.0
https://lists.oasis-open.org/archives/dita/201702/msg00033.html (Eric Sirois, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00035.html (Eric Sirois, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00038.html (Kimber, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00040.html (Nitchie, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00048.html (Swope, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00050.html (Eberlein, 21 February 2017)
https://lists.oasis-open.org/archives/dita/201702/msg00051.html (Kimber, 21 February 2017)
[continued from last week]
Kris did a re-cap; we had decided to open 2 new stage 1 cards; 1) for mods to bookmap in techcontent package and 2) for a new design for a map to replace bookmap; this would be an all-purpose map for deliverables with more functionality than the base map, but not precisely a 'bookmap'.
- Bob; we talked about this at techcontent SC eeting; we're looking at gearing up to look at 1.3 RNG bookmap model to see what would be useful in a re-design. this will be continuing item for SC.
** Action Item; Chris will send mail to TC about his proposal for re-designing bookmap such that it wouldn't break existing docs, by making frontmatter and backmatter optional, and allowing topicref at the root level.
- Eliot; there's a problem with that; because all other major elements (part, chapter, appendix, etc.) in bookmap are already specializations of topicref, doing that removes all contraints from the content model; you could have backmatter at the front and frontmatter at the end.
- Chris; maybe we could just allow certain other specializations at the root level
- Eric; it would be especially nice to be able to create keys at root level.
- Eliot; the main issue is that there's no container into which you can put keydefs, except frontmatter. Maybe we could define a new bookmap specialization of topicgroup that allows keyref.
- Robert; if we allow anything at the start and at the end, that's what undoes the other constraints. We have to pick one location for it.
- Kris; could we pick one location and create a specialization just for keydefs?
- Robert; we could do that for keydefs, but not for ditavalref; putting ditavalref in a container means that that ditavalref applies only to the container, not to bookmap as a whole.
- Eliot; we could allow ditavalref as the first optional child after map.
- Robert; we could do that.
- Eliot; we could use elements from a structual specialization.
- Robert; we might have issues with declaration dependencies, but we could do that.
- Kris; question for the TC as a whole: are the pain points we've heard about largely handled by having keyrefs and ditavalrefs at the beginning?
- Bob; there was also some concern about defining bookmap.
- Eliot; and this is different from having bookmap split into a bunch of domains that are combined in a new bookmap shell.
- Kris; are there other big ticket items that could be addressed with a backwards-compat redesign of bookmap?
- Chris; we need to deal with a glossartref type as an alternative to a glossarylist.
- Scott; I'd agree, that's a big pain point; we're not seeing folks using autogeneration because of glossary issues; they generally craft their own.
- Chris; there's no open source tools to generate them.
- Kris; is there anyone out there doing auto-generated glossaries, to the knowledge of anyone on the call?
[resounding silence]
- Chris; I've thought about it, but never did it.
- Mark; we planning to, for a current client, but haven't done it yet.
- Kris; now let's look at new bookmap design.
- Bob; yes; we really need to decompose bookmap.
[Kris recapped last week's discussion]
1. break it into domains
2. having it part of the base, not techcontent
3; can't use Eliot's pubmap because it doesn't really work for a simple generalized case
- Kris; so first thing, does anyone have a name for this new thing?
- Eliot; only thing that comes to mind is bookmap2...
- Robert; at IBM, we have IBMBook, it imposes more constraints, but doesn't provide much of extraordinary use.
- Chris; I'm a little reluctant to use bookmap2; it would probably make people think they have to understand bookmap to use it. I like publication map; problem is that it exists in Eliot's pubmap, but it is a description of a 'logical' document.
- Eliot; I would be willing give up the 'ownership' of the pubmap name.
- Deb; I'd suggest document map, we're suggesting this also for flyers, white papers, articles and the like.
- Tom; there's also docmap.
- Nancy; I'd suggest using a short name; people are more comfortable with them.
- Robert; docmap would be better than document map; 'document' has an official meaning in XML.
- Kris; any other thoughts about a name? (besides pubmap, docmap, bookmap2)
- Bob; I also think about this as 'deliverables' but don't like the length.
- Deb, master map or ubermap?
- Kris; we have too much about master maps in talking about keydefs, so those terms are overloaded.
- Don; what about something related to docbook assembly?
- Nancy; we don't want to use a name that is exactly the same as a DocBook artifact, and in any case I'd say it's too long a name.
- Scott; note that DocBook assemblies have a section for resources (aka keys, ditavalref), a section for structure, which defines structure, and a relationship section, following the RDF model rather than a table. Are you saying we could borrow the section structure?
- Don; it would be valuable for a way to pull keys from a map without anything else. but it would be a real change to the model for our base map.


7. Continuing item: Formal work on DITA 2.0
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
Process:
Review of cards on project page
Stage one (in progress)
- Nancy; one question; the first card says 'split L&T from base"; aren't they already split?
- Kris; this is about 'what do we do with L&T"
- Eliot; the question is whether we separate it completely from the core spec, like LwD.
- Kris; the main point driving this is that we don't have an active L&T SC, and in fact we're pretty close to shutting it down; do we even have the right people on the TC, with expertise in L&T, to manage it and keep it going?
- Eliot; for 2.0, L&T shouldn't be part of any deliverable of the TC. It needs to be either moved out into the community, or moved to a separate working group. The question is whether anyone would be willing to define a 2.0 L&T; if not, it needs to get 'left behind'.
- Robert; when I hear 'owned by the community' I hear 'left behind'. We could say that someone officially updates it without releasing it as part of the work-product.
- Nancy; but that still requires at least one person willing to update it.
- Eliot; we could put it on Github.
- Robert; the thing is, people see things from OASIS and they think it's OK to use, that it's 'official'; from anywhere else, they don't trust it. So it would be good to have it on a Github with the OASIS name on it.
- Eliot; there are definitely still people using it.
- Kris; yes, I have a client using learning assessment topics.
[Scott, Deb also using it]
- Bob; maybe we could keep it interoperable with 2.0, but not update it.
- Kris; what do we think would be involved in keeping the grammars compatible?
- Eliot; probably not much...
- Robert; I think it would be relatively minimal, just an updated grammar file that complies with 2.0 rules. Of course, if we get rid of any @s in a map, we might have to update L&T to get rid of those, but mostly not much work.
- Kris; I'm not hearing any support for delivering L&T as part of 2.0. I am hearing interest in continuing it as part of 1.3, but also creating a Github repository where the L&T spec and grammar files could go and grammar files could be updated to work with 2.0. And Eliot has expressed willingness to be the point person on that.
[general consensus]
- Stan; if we're getting to where we want to disband L&T SC, we might want to follow the model of the Help SC. For that, we sent out mail to practicioners to poll them on closing the SC.
- Kris; I'd want to check, but I think we've already done that, but I'm not adverse to doing it one more time.
** Actionitem; Kris will post to L&T SC, as well as general TC memmmmmmmmbership and dita-users, with summary of our discussion today, including a note that SC members have to be OASIS members. She will also touch base with Dawn and Amber, who have L&T-using clients.
- Kris; next item is wrt the machinery task. Do we want to bring this forward to 2.0 or not. at least one company in Europe is using it heavily. Is there anyone on the call who knows about anyone using it? For those who want to remove it, what are the arguments?
- Robert; My resistance to shipping it is that we don't have the expertise to maintain it. I think we should treat it like L&T, put it on github and keep it in sync, but don't include it in core
- Kris; at one point we had a machinery task SC, but no more. I'm just concerned that there may be other companies besides the one who spoke to me in Europe.
- Nancy; but putting it on Github would keep it available to folks like that.
- Robert; and putting it Github makes it more available.
- Kris; i personally feel less necessity to move machinerytask, because of its small size.
- Robert; I understand, but it's a domain that has never made sense to me.
- Nancy; I think, if we're cleaning house at 2.0, it makes sense to remove machinery task, as long it continues to be made available on Github and kept interoperable with 2.0.
- Chris; at some point I'm going to put forward a proposal to remove techcontent completely from the core, like LwD.
- Kris; I think we have alredy agreed to that.
- Mark; I like that idea.
- Kris; the proposal is to have techcontent and the core spec as separate work products. Techcontent would be built on top of the 2.0 base, but be a separate work product, to faciitate updating the two things in the future without having them remain completely synchronous, allow for separate deliverables.
- Nancy; so what you're saying about machinery task, is that you'd like it to stay part of techcontent, which would be a separate deliverable anyway.
- Kris; yes




12 noon ET close


-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 21 March 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-03-21 10:01:16



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