dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Scoping DITA 1.0 [was: OASIS DITA TC: 07 December 2004 meetingreminder]
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Paul Grosso" <pgrosso@arbortext.com>
- Date: Tue, 7 Dec 2004 12:53:54 -0500
During the call I advocated adding a
topic to the spec that laid out the costs/benefits for creating new base
classes, and potentially covering recommendations for ways to minimize
breakage of the architecture when/if breakage becomes inevitable (for example,
if new metadata requirements are absolutely required, and otherprops is
not acceptable as a workaround).
But I also feel a bit twitchy about
having a section of the specification that effectively introduces a continuum
of compliance. I think we do need to talk about these issues, and certainly
address them post-1.0, but maybe for 1.0 itself the discussion should take
place in an external best practices document, where we are also planning
to discuss relationships to other standards, etc.
Thoughts?
Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada phone: 416-915-8262
Toronto Information Development
"Paul Grosso"
<pgrosso@arbortext.com>
12/07/2004 12:42 PM
|
To
| "DITA TC list "
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
| [dita] Scoping DITA 1.0 [was:
OASIS DITA TC: 07 December 2004 meeting reminder] |
|
I still prefer the minimalist
approach to our 1.0 deliverable. When we
were discussing and voting on
our charter, I understood that our
first deliverable--DITA 1.0--was
pretty much going to be a "rubber
stamping" of the existing
IBM standard and current practice with DITA.
We have a second deliverable with
which to get more creative.
As much as I agree it would be
worthwhile to expand the applicability
of DITA techniques beyond the
scope of DITA 1.0, I don't feel that we
should do that in the1.0 timeframe.
I have been on too many standards
committees that take so long to
get out their first release that they
miss the optimal window of opportunity;
I'd like to avoid that with DITA.
Before we get out our first deliverable,
I would not spend time trying to
explain how to use specialization
outside of the DITA tag set. And I
would also leave to post-1.0 the
enhancements to <tm> and <keyword>
below.
All that said, if the rest of
those in the TC don't share my opinion, I'll bow
to the majority on this. The last
thing I want to do is add to the time to our
first deliverable by spending
another telcon on this issue.
paul
From: Don Day [mailto:dond@us.ibm.com]
Sent: Tuesday, 07 December, 2004 9:21
To: DITA TC list
Subject: [dita] OASIS DITA TC: 07 December 2004 meeting reminder
3. Specification status
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/10226/ditaspec.pdf
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/10225/ditaspec.chm
"issues for discussion in specification" (start from "Domains
attribute")
http://lists.oasis-open.org/archives/dita/200411/msg00022.html
4. List issues (triage as potential post-1.0):
- Bugs reported on current DITA DTDs and Schemas
http://lists.oasis-open.org/archives/dita/200411/msg00023.html
- Should <tm> allow images or logoized content?
http://lists.oasis-open.org/archives/dita/200411/msg00024.html
- Should <keyword> be allowed to nest?
http://lists.oasis-open.org/archives/dita/200411/msg00025.html
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]