← Prev in month
← Prev in thread
Next in thread →
Next in month →
Re: [dita] Groups - DITA TC Meeting Minutes 5 July 2016 uploaded
Nancy, can you make a few corrections to the minutes? In-line
notes in blue below. Thanks.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
On 7/11/2016 2:16 AM, Nancy Harrison
wrote:
Submitter's message
Action Items:
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:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: none
Standing Business
=================
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
Subcommittee Reports
none
Business
========
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)
2. Announcements:
New DITA TC members: None
New DITA TC voting member: Maria Essig, Healthwise
Results of ballot for OASIS Board of Directors
X
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
https://wiki.oasis-open.org/dita/DITA%201.3%20Errata
DITA-1.3-errata-schedule
Team members:
Editors: Robert Anderson and Kris Eberlein
Style sheets: Bob Thomas
Build: Nancy Harrison
Reviews: Joe Storbeck
SEO and Google analytics: Keith Schengli-Roberts
Work items:
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
Style sheets
Build process
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"
[no updates]
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 to
disallow <topicref> and only allow <keydef>,
<mapref>, and <topicgroup> instead. 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 tasktroubleshooting.
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 buried
than example topics.
12:00 PM ET Close
-- Ms. Nancy Harrison
Document Name:
DITA
TC Meeting Minutes 5 July 2016
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: 2016-07-10 23:16:20
← Prev in month
← Prev in thread
Next in thread →
Next in month →