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] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded


Hi there,

 

I had a couple of additional items that I hope you can clarify:

·         In the requirements list, one of the requirements is “function responsible for validation”. In reviewing the proposed support, I didn’t see any specific element that seemed to support this requirement. Is the requirement that you be able to identify the organization or person who validates the change? Or is there some other intent?

·         Did you consider the requirement to identify the person or group requesting the change? In cases where there isn’t a formal system with an ID, this could be useful.

·         For the date support, is there a specific intent for the separate elements? For example, is the <change-started> to indicate the date the change was made in the file and the <change-completed> to indicate the date it was validated?

·         In the requirements list, one of the requirements is “regulatory-relevance”. In reviewing the proposed support, I didn’t see any specific element that seemed to support this. Is the intent that you would enter this in the summary?

 

Thanks for your assistance,

Amber

 

From: Amber Swope [mailto:amber@ditastrategies.com]
Sent: Friday, August 30, 2013 1:53 PM
To: 'Tom Cihak'; 'dita@lists.oasis-open.org'
Cc: Seraphim Larsen (seraphim.l.larsen@intel.com)
Subject: RE: [dita] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded

 

Tom,

 

I reviewed the proposal in light of my clients’ requirements and really liked the way you propose to handle the multiple-product/concurrent release challenge. Overall, I think that the strategy of using the topic <prolog> and the structure of the domain are sound.

 

However, the one item I didn’t see addressed is the requirement to visually indicate the exact location of the change in the content of the topic. It seems to me that the <change-item> needs to reference the modified element and it comes down to the selection of the appropriate DITA referencing mechanism. Has the subcommittee considered the options for providing this support?

 

The challenge for many teams is the they need to visually indicate changes between releases of a deliverable, but the track changes features in most tools don’t work for the following reasons:

·         author may want to identify a subset of content changes based on specific criteria, such as importance or relevance

·         changes may not correspond cleanly to the workflow versions/revisions of the topic file and the releases of the deliverable

 

Thanks and have a great weekend,

Amber

 

Amber Swope

dita specialist

<dita strategies>

503.922.3038

amber@ditastrategies.com

 

 

 

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Tom Cihak
Sent: Friday, August 23, 2013 1:34 PM
To: dita@lists.oasis-open.org
Subject: [dita] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded

 

Submitter's message
PDF version of release management stage 2 proposal
-- Tom Cihak

Document Name: Proposal 13102, Stage 2 Release Management (PDF)


Description
Proposal 13102, Stage 2 Release Management PDF
Download Latest Revision
Public Download Link


Submitter: Tom Cihak
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Drafts
Date submitted: 2013-08-23 13:33:50

 



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