[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA TC Minutes -- 10 Aug 2004
DITA TECHNICAL COMMITTEE -- MEETING MINUTES -- 10 AUG 2004 *** Please see Action Items and Decision Summary at the end *** ** Agenda ** ------------ 1. Roll call 2. Review/approve minutes from 03 August (pending) 3. Progress on remaining issues currently in discussion. - Normative version--DTDs or Schemas? - Namespace for DITA? - Which version of CALS table model? - Conref and XInclude? 4. Review/revise intro section for the initial specifications. - Content: - Latest version: - http://www.oasis-open.org/apps/org/workgroup/dita/download.php/8636/dita spec-intro-08102004.chm - Schedule: - 17 Aug 2004 - First major milestone -- complete first draft of first section and send out for review. - Begin review of 1st section. - 07 Sep 2004 - Complete review/revision of 1st section; begin review of 2nd section. - 28 Sep 2004 - Complete review/revision of 2nd section; begin review of 3rd section. - 19 Oct 2004 - Complete review/revision of 3rd section; beginning of final review - 02 Nov 2004 - Complete final review - 16 Nov 2004 - Release 1.0 spec to OASIS 5. AOB? ** Minutes ** ------------- 1. Roll call - We do have quorum. 2. Review/approve minutes from 03 August (pending) - Minutes approved. 3. Progress on remaining issues currently in discussion. - Normative version -- DTDs or Schemas? - Discussion: - Eliot Kimber -- The DTD/Schema is not enough to provide a complete definition. The language reference should be the "normative" definition. - Nancy Harrison -- In the DocBook TC, the DTD/Schema is not enough -- the documentation is a very important part of the normative definition. The online version of the documentation is kept on sourceforge along with the code. - Erik Hennum -- The DTD would still be normative for the content model, but the language reference provides the explanation for the same elements. - Debbie Lapeyre -- Supports Elliot in acknowledging that whatever we can say in the DTD/Schema is only a small part of what we are doing. The important part is in the explanation. - Nancy -- Is the DTD/Schema plus the Language Reference adequate, or do we need even more than that? - Eliot -- The Language Reference does seem to be complete. - ... - Erik Hennum -- Proposes that we rely on the DTD for content models and specialization package organization, and rely on the language reference for what it all means. A model in the future would rely on a syntax-independent definition of the semantics, and from this the DTD/schema would be derived. - Eliot -- Need to add a high-level description of the packages -- what is a topic? what is a concept/task/reference? This needs to be included in the language reference. - Bruce Esrig -- Do we need to say anything about processing? - Don -- It's covered in the language reference, although it's not perfect in that respect. - Eliot -- We don't want to talk about how the processing is implemented. - Don -- We need to make sure the Language Reference is complete in regard to processing. - Bruce -- Is the processing semantics implicit in the Language Reference, or do we need to say something explicitly? - Eliot -- What processing semantics specifically are we talking about? In how much detail should DITA specify this / how general should the specification be? - Erik -- We might make these kinds of statements as illustrations, we shouldn't make them as normative restraints. "This kind of thing will typically be rendered as a link." - Nancy -- The processing application will determine how this is rendered. There are some elements that are created for the purpose to do something with them, but not all elements require presentation. You should say something about how an item is typically rendered. - Eliot -- Yes, but it doesn't say "It must be rendered this way." - Bruce -- These mechanisms must be completely described. - Eliot -- If some elements have relationships with other elements, we need to explicitly define those relationships, but that's all, we don't need to go beyond that. - Bruce -- - Don -- This is all good input for the review process, but we don't need to rewrite the given proposal. - Eliot -- We'll provide at least one thorough example of how things should work, but this example won't be the normative definition. - PROPOSAL -- The normative definition of DITA consists of the element semantics and package organization as described in the Language Reference, and the element content models and attribute typing and specialization pattern as encoded in the DTD. - The proposal was approved -- no objections. - Namespace for DITA? - Moved to next week. - Which version of CALS table model? - A lot of discussion on the virtues of the HTML model, the CALS exchange model, and the CALS model. - Some issues considered -- - Can you get required print quality using HTML model, which allows you to specify line widths only as pixels? >>> No - Is there a way to specify cell shading in the CALS model? >>> Yes, you can use attributes to do this. - PROPOSAL -- We recommend a CALS table model -- the HTML model is not required for this version of the specification. We still need to decide which CALS model to use (full CALS model, or CALS Exchange model). - The proposal was approved -- no objections. - Need to resolve final question -- which CALS model to use. That discussion is moved to next week. - Conref and XInclude? - Moved to next week. 4. Review/revise intro section for the initial specifications. - Content: - Latest version: - http://www.oasis-open.org/apps/org/workgroup/dita/download.php/8636/dita spec-intro-08102004.chm - Schedule: - 17 Aug 2004 - First major milestone -- complete first draft of first section and send out for review. - Begin review of 1st section. - 07 Sep 2004 - Complete review/revision of 1st section; begin review of 2nd section. - 28 Sep 2004 - Complete review/revision of 2nd section; begin review of 3rd section. - 19 Oct 2004 - Complete review/revision of 3rd section; beginning of final review - 02 Nov 2004 - Complete final review - 16 Nov 2004 - Release 1.0 spec to OASIS - Action Required: Let's discuss this on the list! 5. AOB? - None ** Summary of Decisions ** -------------------------- - Approved minutes of 03 August. - Decision -- The normative definition of DITA consists of the element semantics and package organization as described in the Language Reference, and the element content models and attribute typing and specialization pattern as encoded in the DTD. - Decision -- We recommend a CALS table model -- the HTML model is not required for this version of the specification. We still need to decide which CALS model to use (full CALS model, or CALS Exchange model). ** Action Required ** --------------------- 017 Shawn Jordan -- Post to the TC list his ideas about general extensibility and the creation of new elements not necessarily descended from the Topic element. Still open (not an immediate deliverable -- for post-1.0). 021 JoAnn Hackos, Michael Priestley -- Summarize the discussion of substitution and post to the TC list. Still pending as of 7/20/04. 022 Don, Michael -- Put together a "self-study" tutorial/demo, as per JoAnn's comments regarding the DITA sessions. Still pending as of 7/20/04. 024 Eliot -- Find out exactly how to entitle the subsections within the two specifications (as "sub specification", or as "Part 1, part 2, etc.", or in some other way). - Eliot sent email to specification support person, but no response back yet. (6/29/04) - Also Eliot should ask if OASIS can provide any examples of well-written specs (in regard to content, not format) 026 Michael -- See how Conref and XInclude contrast with SGML. Still pending as of 7/20/04. 027 Erik Hennum -- Wrap up his thoughts about Conref and XInclude and put them on the list. Still pending as of 7/27/04. 036 Shawn Jordan -- Investigate where to point the DITA namespace -- where does the URL point? Maybe an OASIS page that describes what DITA does, etc. 037 Don -- Find someone to investigate the impact on those with legacy content of moving from the CALS model to the HTML model. 040 Don -- Cull the past minutes and discussion list to create an inventory of all the things we need to close on in order to create the 1.0 spec. Create a list of these items and post it in the Documents area of the website. 041 All -- Send comments on spec 1.0 to JoAnn this week. 042 All -- Consider need for and practicality of 2-3 day face-to-face meeting in late October in order to resolve final technical issues in advance of final editorial work. 043 Michael Priestley -- Add a straw-man audience statement to the introduction. 044 All -- Review the .chm file sent out by Michael Priestley located at http://www.oasis-open.org/apps/org/workgroup/dita/download.php/8636/dita spec-intro-08102004.chm and post comments to the TC list. ** Issues to be Resolved ** --------------------------- 005 All -- What should the scope and length of the conceptual introduction be? 006 All -- Should DITA specialization mechanism be documented in a separate specification in order to make it easier to use in other XML applications that otherwise have no relationship to topic-based writing? 007 All -- Decide which version of the CALS table model to use -- either the full CALS model, or the CALS Exchange model. <END> ___________________________________________________________ Seraphim Larsen ICG Technical Publications Sr. Technical Writer Intel Corporation (480) 552-6504 Chandler, AZ The content of this message is my personal opinion only. Although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___________________________________________________________
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]