Nancy, it looks as if the minutes
contain some of the content from the 7 October meeting. Can you
revise and re-upload, please? Thanks.
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+1 919 682-2290; kriseberlein (skype)
On 10/21/2014 9:48 AM, Nancy Harrison wrote:
Minutes of the OASIS DITA TC
Tuesday, 14 October 2014
Recorded by Nancy Harrison
link to agenda for this meeting:
Regrets: Dick Hamilton
Approve minutes from previous business meetings:
(16 September, Don Day)
(7 October, Nancy Harrison)
Proposed by Kris, seconded by ??, approved by TC
Subcommittee Reports: Adoption SC
Joann: noted work on a number of feature articles and plans to
update xml.org. Lots of articles are scheduled, but hasn't been a
lot of progress on having draft articles written. So all TC
members, please help out with this.
1. DITA 1.3 progress First spec review (Eberlein & Anderson)
Transformation utilities and DITA 1.3 grammar files (Kimber)
Robert: I've been making a lot of changes, updating things based
on Trello 'improvements' item. I recently uploaded a bunch of
tools I used to create contained/containment tables, something I
never did it at 1.2. I updated ant scripts, and readme file; Kris
tested and was able to build. Tools are in svn/containment. got a
branched copy of some of Eliot's RNG code, since his version is
newer than these.
Kris; readme file is very clear
Robert; one thing missing is easier to generate tables for new
doctypes, other than the ones in the dtd directory, for folks
creating their own specializations.
Kris; Eliot, any updates on transformations?
Eliot; no updates, the only outstanding item is generating good
versions of L&T shells. DTDs are all logged in.
2. Action items
- Action items from 19 August 2014
Shells for L & T: Robert, Kris, Eliot, and John to meet when
John is back from vacation; being scheduled.
Kris; trying to schedule; we need to clear this.
Robert; I'll take on this AI.
- Action items from 26 August 2014:
Nancy will review specialization and constraints topics, with the
a) suggesting placement for new topic or content chunk,
b) reviewing for clarity, organization, technical accuracy.
This is in regard to content about limitations of XSD shells and
constraints. (Waiting on Kris to generate new versions of spec,
which was done 7 October 2014)
- Action items from 2 September:
Stan to assess Front Page wiki for possible clean-up
- Action items from 16 September:
Robert will send details about necessary OASIS comments in grammar
files to Eliot.
NEW AxtionItem from 14 Oct.: Robert will schedule meeting on
L&T shells with Kris, Eliot, John, and himself.
3. Update on first meeting of Lightweight DITA (LD) SC
Michael: we've had 2 meetings, will meet bi-weekly. We talked
about goals of SC and LD. reviewed use cases and stakeholder
roles, asssigned folks to look at permutations of those, e.g. how
LD might be used within software dev. by different organizations;
e.g. mktg, dev, writing, support.
We've got a whole group of folks, represents large range of
reasons for using LD, shows applicability of LD to variouos areas.
Over next meetings, SC members will report back on user roles,
scenarios, and business cases.
Kris; who's been at meetings and where are they from?
Michael: ~20 members registered, about 1/2 to 2/3 of that number
are on the actual calls.
Kris; attendance has been very high, ~14/15 at each call.
Michael; lots of folks from DITA tech companies and consultants,
and from different industry backgrounds; sfw, medical device
content, machine industry. Also, folks from various continents, so
4. Announcement of 2nd spec review: 10 - 24 October 2014
Wiki page contains:
Download link for official review draft
Tracking tables for review assignments
Information about prizes (yet to be determined)
Kris went over review goals and requirements, there are no updates
to cover page or footer info; will have errata and revision info
Objectives for this review:
all of key--based content particularly in indirect key-based
material; question, is there material in other sections that has
to be aligned with this? Need serious attention to this.
Robert; in rework, we rewrote everything, so please review it!!
Key section was completely overhauled, focuses on core concepts
needed for working with keys, also completely reworked key
processing topics; was one huge topic, now split apart and more
tightly focused. Last rework is example topic, previously one
example topic with many unorganized examples, Kris broke that up
into multiple organized eamples. substantial overhaul of indirect
addressing section of spec; we need this to be seriously reviewed
Kris; that's the #1 priority for review; #2 is branch filtering.
Robert; that was reworked in response to many comments in last
Kris; I also reworked subjectScheme material, this also needs
serious review, it now includes normative language, broke it apart
into multiple topics.
Kris; also please really look at draft-comments; we need to
5. Solicitation of volunteers for specific spec review assignments
Trello cards from the "Spec clarification and improvement list
willingness to go to Trello card, investigate associated
materials, add comments in DITAWeb on how to addresst the issue
need to have work completed during spec review (by end of Oct)
2, 25, 8 all constraints, Bob Thomas? Nancy (both agreed to look
at them and possibly volunteer)
6. Prizes for review #2:
Volunteer to collect and mail prizes?
Kris asked for volunteers for ocllect/mail
DickH and Joann (books) and Eliot (bacon)
Stan will collect/mail
7. Question about keyref and replacement text
(Anderson, 22 September 2014)
Robert; getting text for a keyref uses complicated rules to choose
the text but all rules eventually default to linktext element. So
do we want to note up front that if you want consistent text, put
it in linktext?
Kris; examples in 1.2; one showed pulling from keyword, another
from linktext. Going forward, we should only show pulling from
Michael; 'if you want the text to be the same in every example,
use linktext' is useful, but people might actually have reasons
for getting different text. Still, if all you want is the same
thing, use linktext.
Robert; the edge cases are part of the spec, and need to remain
there. I think there are very few people who understand
inheritance well enought to understand the edge case.
Michael; but an element can pull text from a matching element
name. so it's worth documenting the edge case.
Robert; that is covered in the new content.
Kris; should Robert just change the spec source? Give an
Robert; I'm planning to update the text.
Kris; Robert, go ahead and update spec text, Michael, please craft
an example if you think it needs one.
8. Question about domains attribute
(Anderson, 3 October 2014)
Robert; came up with pure example is a value required for domains?
In 1.2, the spec clearly encourages that we add the @domains. I
was surprised to hear about tokens added by Eliot 'map map' and
Eliot; in the last case, the first token says 'what kind of thing
am I?' (map or topic) and second, what kind of map;/topic am I?
Robert; I don't understand why you would want to declare that.
That info is already in @class, so if we have this token, it
should just be 'map' 'topic' on its own. These tokens are going in
Kris; so these currently exist in 1.3?
Eliot; that's how I specified base attribution for base map and
topic. The spec needs to make it clear that these are required.
Robert; people conref between maps and topics; will this make that
Eliot; we'll need to specifically allow that case. in 1.1 we
allowed the case where no domains exist.
Robert; I still don't think we've thought it thru.
Eliot; so your proposal is that ...?
Robert; my gut reaction is that we shouldn't be adding these
tokens at all.
Eliot; in 1.2 we say that a dita map/topic is formally defined by
the domains attribute. so I think we need to have a value there
Robert; I'm wary about that. it's often been talked about, but
I've never encountered a scenario where it was useful. especially
where there are caveats and extra required rules.
Eliot; but don't we have that now, just not explicitly noted?
Robert; not sure what impact it would have on conref, if any...
don't know if this token will confuse that processing.
Kris; we always need to be careful of artifacts creeping in that
we haven't formally dioscussed.
Eliot; part of the problem is that @domains is underspecified;
does spec allow or disallow this what you specify for base map or
base topic? if that's the case, what can/should/must the @domains
Robert; or we leave the status quo, and it's not answered.
Kris; we have only 1 minute left
REsolution: leave this on agenda for next week. let's discuss on
listserv as well.
TC members should keep their eyes open for email announcing start
closed at 11:59 EDT
-- Nancy Harrison