dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] On the DITAVAL file
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Chris Wong" <cwong@idiominc.com>
- Date: Tue, 7 Feb 2006 10:17:59 -0500
The use case is less about version management
and more about producing drafts or new revisions of a document that highlight
what changes have been made since the last revision. Since not all changes
are worth drawing attention to (eg minor grammatical corrections or style
changes), typically it gets set directly by the author during the editing
process.
Sometimes it gets set for flagging only
during the internal review draft, to help reviewers focus in on changed
parts of the docs (for example, if an install procedure is exactly the
same as last release except for two or three steps or an install path,
the writer would put a rev attribute on those steps, and the reviewer could
quickly verify that those changes were accurate).
There are times where the end-user cares
about differences as well, however: let's say for a product where most
users are familiar with the previous version and work with it daily (perhaps
as administrators) and won't be reading the documentation in depth but
do want to be able to gloss the tasks they perform daily to see where they
need to vary their procedure.
Hope this makes sense,
Michael Priestley
IBM DITA Architect
Classification Schema PDT Lead
mpriestl@ca.ibm.com
"Chris Wong"
<cwong@idiominc.com>
02/07/2006 10:00 AM
|
To
| "Jennifer Linton"
<jennifer.linton@comtech-serv.com>, "DITA-TC \(E-mail\)"
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [dita] On the DITAVAL
file |
|
Something that I never really
understood is the usefulness of @rev and the corresponding revprops element
in DITAVAL. Traditional versioning (CVS/ClearCase/Subversion/etc) operates
at the file level, which means we do version diffs at the topic level at
best. Having revision markers down to the phrase level always seemed unmanageable
to me: most versioning software would not support that. We just end up
using using versioning software to get 2 revisions of a DITA file (topic)
and diffing those with an XML differ to generate revision markup.
How do you (and IBM) use @rev/revprops?
Chris
-----Original Message-----
From: Jennifer Linton [mailto:jennifer.linton@comtech-serv.com]
Sent: Tuesday, January 31, 2006 9:48 PM
To: DITA-TC (E-mail)
Subject: RE: [dita] On the DITAVAL file
Chris,
I too think that the DITAVAL file
as it is with the ability to do revision marking and flagging. We get a
lot of questions from clients who would like to do that and see the benefit
of it. I also would like to use it and would do so if we can get the transforms
in the open toolkit to work correctly out of the box.
I do see a great need for this
functionality though.
Jen
From: Chris Wong [mailto:cwong@idiominc.com]
Sent: Tuesday, January 31, 2006 10:23 AM
To: DITA-TC (E-mail)
Subject: [dita] On the DITAVAL file
What do we want to accomplish with the
DITAVAL file? I see it as useful for specifying deliverable content, much
like a DITA map, but this is only the filtering part of the file. When
we (Idiom) discussed supporting DITAVAL, it just seemed overengineered
when all people were asking for was conditional text. Nobody was requesting
flagging nor revision marking.
Is anyone using the revprops part of DITAVAL?
Or flagging? These parts determine appearance, not content. I'm just trying
to get a handle on the different applications of DITAVAL.
Chris
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]