[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-comment] Filter content based on the "rev" attribute
|
Hi David, You have precisely described our flow: 1. Writers apply @rev to flag revised content. 2. Subject matter experts review the @rev-highlighted content. 3. At release time, we clear all the @rev flags via a refactoring operation. Hi Radu, I wonder if the customer requests are equating ârevisionâ to âversionâ? These are different concepts (authoring development markup versus customer-facing content profiling) that I feel should be kept separate.
From: David Artman <David@DavidArtman.com> Another way to consider it is that @rev is for the *content's* development between vrms, not the *product's*. Highlight changes since the last time that your smes read the topics, to speed their reviews. So maybe you yellow highlight additions and red strikeout deletions. Then, yes, after review, you have to physically delete approved removals and (for future cleanliness) remove @rev from approved additions. In short : @rev isn't customer facing. Unless you choose to use it for format control in outputs which address product variants. Which is probably sloppy in the long run, compared to other mechanisms for flagging such variations in 'collective'
or 'comprehensive' outputs. Again : if I'm missing something, please correct me. David Artman DCA:d.a.d -------- Original message -------- From: David Artman <David@DavidArtman.com>
Date: 5/12/21 03:53 (GMT-05:00) To: Radu Coravu <radu_coravu@sync.ro>,
dita-comment@lists.oasis-open.org
Subject: RE: [dita-comment] Filter content based on the "rev" attribute
My understanding of the rev attribute is that it's not intended to be a marker for output (other than format) but a metadata for authoring (and version control). Best used when a single output serves several versions. Or if you're tricky
with xslt, a way to make a mini index or toc of changes between releases (we've done that just for sme reviews, in the past). Inclusion of version-specific content in a topic is better managed at the block level, via conref. Then your tool's version and branching systems will pull the appropriate block for the requested output and version / release. Otherwise, your topic grows constantly, rev by rev, and becomes unwieldy to edit. You could also lose branching capability (or go mad trying to fake branching with pseudo revs). If I'm wrong or missing a nuance, I look forward to correction and more details! David Artman DCA:d.a.d -------- Original message -------- From: Radu Coravu <radu_coravu@sync.ro>
Date: 5/12/21 02:32 (GMT-05:00) Subject: [dita-comment] Filter content based on the "rev" attribute
Hi, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]