Groups - DITA TC Meeting Minutes 25 March 2014 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        Action Items (listed in order of due dates)

For Apr 1:
1. Eliot will work on generation of 'contains/contained by' material
2. Eliot will work with Robert on incorporating that into arch spec generation
3. Robert will have spec generation in workable shape
4. Kris will add DITA website item to TC agenda

For Apr 8:
1. Robert will have prototype for arch spec generation available

For Apr 15:
1. Robert, Eliot, Chris, David, and Scott will have initial draft of test plan for 1.3
=========================================================
Minutes of the OASIS DITA TC
Tuesday, 25 March 2014
Recorded by N. Harrison
link to agenda for this meeting:	
	https://wiki.oasis-open.org/dita/PreviousAgendas

regrets:   Bissantz 

Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201403/msg00176.html (18 March, Nancy Harrison)        
Proposed by Kris, seconded by Dick, approved by TC
Since Nancy will be not be available to do minutes for the next 3 weeks, Kris is asking for volunteers.
Stan will take minutes next meeting, April 1. 

Subcommittee Reports
	none (TechComm SC April 6)

Announcements
	none


Business
========
1. DITA 1.3 progress
RelaxNG-to-DTD and RelaxNG-to-XSD transformations (Kimber)
DITA 1.3 grammar files (XSD) (Kimber)
  - not quite done; has completed generation of RNC
  - took longer to set up testing framework, but it's moving
  - new expected date; next Tuesday.
Action Items for Eliot: for Apr 1
  1. Redesign of "Contains and Contains by" (Anderson) 
  2. work with Robert (below)

Redesign of "Contains and Contains by" (Anderson) 
- Robert; could use some input from Eliot, when I run your prototype for generating info, get some crashes; will send you a note to see if you have new input; 
- Eliot; what I sent you was a really quick hack...
- Kris; Robert, what is a realistic date to have spec generation redesign completed?
	- what help do you need?
	- what is a good set of milestones?
Actions for Robert: 
  1. Robert will have stuff in workable shape by next week
  2. Robert will have an early prototype by Apr 8th


2. First spec review: 2-16 March 2014 (Eberlein, Anderson)
Update on comments not yet worked
	- 192 on arch spec
	- 82 on langref

Problem areas
	- architecture spec; areas of keys, keyscope, keys terminology
	- branch filtering
	- new cascade attribute
	- doctype shells constraints
- Kris; Robert and I need to figure out how we can not be bottelnecks
- Robert; in the language ref part of spec, the stuff that's the hardest to integrate and needs the most TC review already has had some review.  With Kris, did a quick triage of easy, med, hard to resolve comments.
- Kris; one concern is that we had multiple folks working on sections in the arch. spec. in 1.2, and that became a problem. 

Update on editors' experience using DITAweb to work comments
- Kris; we're going to need some tweaks to ditaweb; no way to get good analytic summary of comments. no indication from standard view for showing whether comments are resolved/rejected or open

Plan for completion 
Kris;; based on our count, we've handled more than 2/3, but still a lot of work to figure out.


3. New item: Plan for testing and approving 1.2 and 1.3 files generated by Eliot Kimber
    https://lists.oasis-open.org/archives/dita/201403/msg00167.html (1.3 doctypes and DITA-OT plug-in)
    https://lists.oasis-open.org/archives/dita/201403/msg00168.html (1.3 DTDs and RELAX NG)
    https://lists.oasis-open.org/archives/dita/201403/msg00169.html (1.3 doctype test documents)
    All above links point to resources uploaded by Kimber on 18 March 2014 
- Robert gave an overview; with 1.2, I had a ugly set of tools that would turn the spec into a set of test documents; this resulted in a couple of changes around the way, but it wasn't easy or foolproof.  We need something better. For 1.3, I'd like to first do a diff with the original shipped 1.2 files, to see if all  the elements and attributes are correct. But that just tests 1.2, not 1.3, since Eliot's already integrated all the 1.3 proposals into RNG.
- Eliot; that's true; there are a couple of places where implementing one proposal had an impact on implementation of other proposals that wasn't reflected in the proposal documentation. When I implemented a proposal, I created test cases showing that new functionality
- Robert; we need to bring those kind of changes back to the TC for approval.
- Chris; I spent some time working to integrate Eliot's files, and found some anomalies; I used a tool we (at Oberon) have; that tool doen't make sense for a lot of the TC work, but it might be helpful to find things appearing where they shouldn't. The tool is based on a SAX filter to double-check elements (it's a tool that might be developed further on).
- Robert; in 1.2, we focused on making sure we didn't introduce unintentional changes; we want to define things so the intended use case works, and also, so we don't cause havoc elsewhere.
- Eliot; the .rng files have very consistent structure, so a line diff between 1.2 and 1.3 files should give a very clear diff.
- Robert; what I did with 1.2 was to expand every parameter reference; when they were expanded, problems and anomalies showed up.
- Eliot; part of my processing structure does that expansion; so we may be able to create something equivalent to what you describe.
- Robert; I expected that, since that's needed for contans/contained by.
- Eliot; also, a tool to create a fully normalized form of the grammar would be good, but I didn't need it, so I didn't create it.
- Kris; can you 2 get together with anyone else who might get involved and come back with a clear plan for how we can move forward and resolve this issue?
- Eliot; I'm happy to work with folks, but not before I delive XSD stuff.
[Chris, DavidH, and Scott volunteered to work with Robert on this.]
- Kris; Let's set as an initial due date the middle of April (4/15) TC meeting.


4. New item: Organization pattern for XML catalogs
    https://lists.oasis-open.org/archives/dita/201403/msg00180.html (Kimber, 22 March 2014) 
Eliot gave an overview; the way catalogs are organized in 1.2 and earlier, and the way they're organized in DITA OT is just one big catalog; for 1.3, I want to generate a more modular set of catalogs, 1 per package per schema type, in preparation for packaging the DITA OT vocabulary as a plugin. This came out of creating a tool for catalog generation.
Robert; The catalog as distributed by OASIS is simply a convenience, not required in any way.
Kris; anyone have any concerns?
Chris; Those who do use the OASIS catalog just link it in, so as long as you can still do that, there's no problem.  Is there a formal plan to get Eliot's tools out into the community?
Kris; that's always been the plan; that those utilities would be made available; I'm still talking to Chet Ensign to see if OASIS should be involved or if we should just go thru SourceForge or GitHub.
Eliot; my preference would be to have some DITA site analogous to docbook.org.
[discussion on independent DITA site and where utilities should be located...]
ActionItem; add agenda item for dita website for next week.


5. New item: Normative statements and file-naming conventions
    https://lists.oasis-open.org/archives/dita/201402/msg00133.html (Eberlein, 17 February 2014) 
Kris gave an overview; our constraint module conventions don't match the names in the examples, or the names as we shipped them (which match the examples).  We had used normative SHOULD in our Terminology topic. In addition, in our File Extension topic, we use a normative MUST to define file names for a number of items, including constraint modules (this topic doesn't include any internal contradictions).
- Kris; We should corrective the normative wording (i.e. change names as given with the normative SHOULD to the ones we ship, which match the examples, and also should change the MUST to a SHOULD), both in those 2 topics and anywhere else it exists
- Eliot; the problem is only in the locations noted.
- Kris; as I read constraints topic, I wondered why we were using a SHOULD instead of MUST; do they affect interoperability? If we have a purpose for why they need to be a particular style, we should say so.
- Eliot; I should be able to take a set of DITA doctype shells from anyone who's created them, and know what's in them.
- Robert; I don't agree; it's nice for consistency, but it's not necessary for working. some of this mandating language really bothers me. 
- Kris; we do have another file naming topic which uses a normative MUST, which is so loose as to be ridiculous.
- Eliot; this came up with constraints because file names could be impossible to understand.
- Chris; doctype shells generation is hard, rules make them easier
- Robert; they're a bit annoying
- Kris; as a practicioner, I follow strict rules, which helps my clients, but looking at the normative language, it seems a bit out of whack; some places have to do with interoperability, and some is just best practices.
- Chris; things that make it easier to share things are part of best practice
[to be continued next week]



meeting closed at 11:59

        
-- Nancy Harrison

Document Name: DITA TC Meeting Minutes 25 March 2014

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2014-03-27 15:23:01