| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 5 July 2016 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Sun, 10 Jul 2016 23:16:39 -0700 (PDT)
1. Kris will tweet a welcome via our new twitter feed and also post a link to the 1.3 spec, and the committee note "Why 3 editions" on it.
2. Eric will test the XSD versions of the learningObjectMap and learningGroMap to see if they work correctly.
3. Robert will add to the list of 2.0 items; redo conceptual topics in spec that describe the various topic types, duplicating the information in the content models.
4. Robert will add to the list of 2.0 items; consider the idea of a) separating technical content from base, b) separating machinery task specialization from technical content, and c) not including the machinery task as part of 2.0.
5. Kris will post the question 'who's using the machinery task? OOTB? as basis for creating company specific shells?'
6. Kris will add an item to weekly TC agenda for checkins on our 2 open Github repositories (Eliot's tools one and the LwD one) to track whether there has been any activity in either.
Minutes of the OASIS DITA TC
Tuesday, 5 July 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201606/msg00067.html (Tom Magliery, for 28 June 2016)
Proposed by Kris, seconded by Nancy, approved by TC
1. Action items
10 May 2016:
Robert: Content model generation (In progress)
Robert; checked in a new topic to resolve this, can mark it closed. did spot checking, probably need to do more...
7 June 2016:
Michael: Post link to slide share of Webinar
[michael not on call]
21 June 2016:
Kris, Nancy, Bob: Meet about documenting errata items and errata builds
Michael: Provide voting members of TC with link to CIDM Webinar recording
Dick: Review materials about how other TCs use Jira
Dick; did a quick look, but let's continue this for a week, in progress]
28 June 2016:
Eberlein: Create Wiki page for DITA 1.3 errata schedule (COMPLETED)
Anderson: Convene call for DITA TC vs. DITA-OT committee note (COMPLETED)
New DITA TC members: None
New DITA TC voting member: Maria Essig, Healthwise
Results of ballot for OASIS Board of Directors
Kris; there's a new twitter handle for our TC, it's #oasis_dita_tc, it came from Keith; The policy for usage is:
- for formal communciations between TC and larger DITA world, right now Kris is only person authorized to use it,
- it's for official TC business, we may need a new item for agenda to track and cover it.
Keith; why don't we use it first to welcome the new person who's just joined as voting member?
ActionItem; Kris will tweet 1) a welcome via our new twitter feed, 2) post a link to 1.3 spec on our tweet, 3) post on our twitter feed a link to our committee note on 'why 1.3 editions?'
3. Continuing item: DITA 1.3 errata
Editors: Robert Anderson and Kris Eberlein
Style sheets: Bob Thomas
Build: Nancy Harrison
Reviews: Joe Storbeck
SEO and Google analytics: Keith Schengli-Roberts
Set up @rev for errata; work errata items related to source (Completed to date)
Catalog files (Completed? New items have surfaced ...)
Correct content model topics
Search engine optimization & Google Analytics
Kris; since Robert's now done the content model, we'll need to add an item for testing content modeling,
4. Continuing item: More Catalog Errata: Public ID for RNG MathML Module
https://lists.oasis-open.org/archives/dita/201606/msg00009.html (Kimber, 9 June 2016)
https://lists.oasis-open.org/archives/dita/201606/msg00010.html (Kimber, 9 June 2016)
https://lists.oasis-open.org/archives/dita/201606/msg00016.html (Kimber, 15 June 2016)
[hold for Eliot]
5. Continuing item: Work on committee notes
Update to "Why Three Editions"
"Upgrading to a new version of DITA" (was "Upgrading to DITA 1.3")
"DITA the standard verus DITA Open Toolkit"
Robert; the working group had a meeting, and made some progress.
6. Continued item: OASIS Jira for DITA TC use?
https://lists.oasis-open.org/archives/dita/201605/msg00038.html (Scott Hudson, 24 May 2016)
Kris; if anyone's interested, look at Scott's notes; note that we're not looking at this as a way of managing our agenda
7. New item: Problem with learningObjectMap, learningGroMap DTDs
https://lists.oasis-open.org/archives/dita/201606/msg00066.html (Anderson, 29 June 2016)
Robert; the issue that was raised is simply what happens with the learning modules; these are 2 new maps added at 1.3, with strong constraints to remove items from the mapgroup domain. It seems like the purpose was to restrict 'topics' from these maps, can the user can only reference learning topics/maps. It was implemented in RNG, in which it's fairly straightforward, but with DTDs it's not so easy, so the DTD module as defined is actually invalid. It was never noticed before, because it's used in the wrong locations in the shells, so the constraint doesn't do anything in the DTD doc shells, though RNG doc shells are valid. So we have a DTD that's more permissive than RNG, so what do we do about that?
Kris; what about XSD?
Robert; Eric had offered to check that; when I tried to set one up, it failed, but I may have done it wrong.
Robt; constraints were generated with the RNG-to-DTD generator, and didn't work correctly; I don't know how the XSDs were generated, but constraints have to be set up differently in XSD to the way they're done in RNG. For XSD, it's very difficult, more complicated, in part because of our strict coding practices/rules about constructing a valid 'module'
Kris; your email outlines options, what about them?
Robert; I don't know what the correct option is. The DTD isn't 'broken', but it doesn't do what we want it to do. One option is to 'fix' the DTD, but that would make the 1.3 DTD invalid. But if this constraint is really useful, we should do that anyway. The other option is to relax RNG rather han tighten DTD. OR we could redo the module, but leave the DTD alone.
Scott; since the module is created thru the conversion, we need to fix it without overwriting with a new conversion.
Robert; we are not regenerating the DTDs, we are doing fixes by hand on 1.3 modules. Eliot might want to fix the tool, but that's a completely different issue. But the issue is that domains don't work the same in RNG as in DTD. The shows the issues with our rules for domains.
John; hats off to Robert for discovering this; sorry we didn't catch this at the time. Robert's description of the L&T SC group's intent was correct.
Robert; I dont' fully understand these, so I don't feel qualified to speak to whether this constraint is so necessary as to make it worth breaking things over.
John; I can reach out to Mark Meyer to see his opinion.
Kris; given that we approved it, and the RNG works, I think we should fix the DTDs and XSDs, and maybe add a new example to the errata spec that covers what we did and how, unless it's too long and gnarly. We broke it; let's fix it and do it quickly.
Robert; and let's be clear; fixing it means the constraints work; the DTD already works, it just doesn't work with constraints the way it's advertised to do.
Kris; this relates to some other issues with content models; maybe we shouldn't make a decision today, but have the discussion. We can't relax RNG if that's a normative change, and there's some overlap with our next agenda item; i.e., are the doc shells really normative, or just exxamples we're shipping?
Scott; I'm not in favor of relaxing the RNG; I'm in favor of fixing the DTD/XSD and associated constraint modules.
ActionItem; Eric will test the XSD versions of the learningObjectMap and learningGroMap to see if they work correctly.
8. New item: Issues noticed with taskbody content model in various task types
https://lists.oasis-open.org/archives/dita/201607/msg00005.html (1 July 2016)
https://lists.oasis-open.org/archives/dita/201607/msg00007.html (3 July 2016)
https://lists.oasis-open.org/archives/dita/201607/msg00008.html (3 July 2016)
Robert; the machinery task has very strict constraints, and when we added tasktroubleshooting to the grammar, the machinery task never got updated, so it doesn't allow troubleshooting. Our concept topic for this task (machinery task) also doesn't say that tasktroubleshooting isn't in it (it's not mentioned as being in it or not in it), since that's a normative topic, I'm not sure what we can do about it.
Kris; so it give us decisions we have to make; there are some places we need to fix grammar items so our spec topics match grammar files. Are our doc shells even normative, or are they examples? It's clear that .mod files are normative, but are the shells themselves really normative as well?
Robert; I think doc shells and constraints should be separate; I think that the constraints we deliver, we have concept topics that describe them and go along with them, including ones for machine task. intended to be normative and to be used as delivered. I could accept shells as normative or as not, but I think we should treat them as normative because we ship them and everyone uses them.
Scott; but we do state specifically in the spec that the RNG shells are the normative ones
Kris; we can't make the same argument here as with the learning map above, that the RNG is correct, since the RNG for machinery task is incorrect.
Bob; I'd say yes also, the same a Scott. For a user, defining a constraint has the same effect as defining a new element. We use constraints to deliver a new content model that's normative.
Robert; Kris thought that doctype shells are an implementation of the normative modules.
Nancy; it may be a gray area, but in light of tradition, I'd say we need to treat them as normative. But what about 2.0?
Robert; I'd still prefer not, but I'm open to conversation.
Bob; my take; it would have been my intention to add it to the machine taskbody constraint, I'd say it should be there; if it should be put in a constraint module; once we add it, it will be perceived as an loosening, rather than a constraint.
Kris; looking at arch. spec. topics that pertain to particular info. types; we have a lot of trouble because we cover content model issues in them, as well as formally in the langref. We need to revisit these concept topics, we have 2 versions, since content model topics that are generated for the langref repeating a lot of information that's also found somewhere else.
ActionItem; Robert will add this to the 2.0 items list; we want to redo conceptual topics that describe the various topic types.
Robert; maybe the machinery topic shouldn't be defined in the core standard, and we should revisit it in 2.0.
Chris; the problem is that for these domain-specific types, maintenance is a problem because owners have dropped off the committee.
Kris; it's in use by some people - Amber has clients that use it - but there's no one to maintain it. Many folks think that at 2.0, the techcomm package should be delivered separately from the core stuff, as L&T will definitely be.
Chris; there are all kinds of reasons to standardize for a specific industry.
ActionItem; Robert will add to 2.0 item list page; the idea of considering the separation of the technical content package from base DITA, as well as separation of the machinery task from techcomm, and removal of the machinery task altogether from 2.0.
Kris; shall we use our new twitter account to ask whether people are using the machinery task?
Robert; I'd hold off till our twitter feed is known about (and followed) by more people.
ActionItem; Kris will post the question 'who's using machinery task, either OOTB or as the basis for creating company specific shells?' to dita-users and dita.sml.org
Chris; or we can put them in an initial 2.0 location on github, but not commit to maintaining them.
Kris; opening up a open repository commits us to having a TC member who takes ownership of it.
ActionItem; Kris will add an item to weekly TC agenda for OASIS open repository checkins; there are 2 open repos, we need to get checkins on activity in both of them (Eliot's tools and LwD)
Kris; so what do we do about constraints and learning maps and the machinery task?
Robert; for the machinery task, we delivered something that's normative and can't be changed. The conceptual topics about strict and general task and troubleshooting, errata should mention that those are normative.
Kris; if we decide that a constraint is normative, do we have a formal way to advise people that this is a problem and give them tips on how to change it? I don't know if we can include in the errata how to fix the constraint module to have it match our original intent...
Robert; it would be a non-normative topic.
Kris; it could be another example, but I don't know if that will be less varied than example topics.
12:00 PM ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]