Re: [dita] Scoping DITA 1.0 [was: OASIS DITA TC: 07 December 2004 meetingreminder]

MHonArc v2.5.0b2 -->

















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 <>
To: "Paul Grosso" <>
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



Dept PRG IBM Canada  phone: 416-915-8262

Toronto Information Development







"Paul Grosso"
<> 
12/07/2004 12:42 PM




To
"DITA TC list "
<>


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:]


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





Follow-Ups:

Re: [dita] Scoping DITA 1.0 [was: OASIS DITA TC: 07 December 2004 	meetingreminder]
From: "W. Eliot Kimber" <>



References:

Scoping DITA 1.0 [was: OASIS DITA TC: 07 December 2004 meeting reminder]
From: "Paul Grosso" <>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]