MHonArc v2.5.0b2 -->
dita message
[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]