OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] On the DITAVAL file



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]