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: Cannot use strike throughs to indicate deletions


Chet, the point is that we do not have a way to indicate (in the actual spec prose) what has been deleted -- it's gone from the XML source. It simply does not exist anymore.

We can, of course, provide a summary that lists changes in detail, for example:

Section
Old text
New text
2.2.2.3 DITA map elements Enables authors to reference a navigation branch that is defined in another DITA map Enables authors to reference a navigation branch that is defined in the current map or in another DITA map

We can, of course, use whatever mechanisms you want (strike through or color) to indicate deletions in this summary, since it is a topic created solely for the purpose of indicating changes.

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 6/22/2016 10:46 AM, Chet Ensign wrote:
Hi Kris - color would be ok. Red for remove, green for add or something along those lines. 

/chet


On Mon, Jun 20, 2016 at 11:06 AM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote:

Guys, we CANNOT use strike through to indicate text that has been removed; that's a Microsoft Word functionality. We CAN use marginal notes and color to indicate content that has been added or modified, as well as provide a list that indicates what all the changes (additions, modifications, deletions) are.

Do we need to talk about this?


Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)



-------- Forwarded Message --------
Subject: [dita] Model Documents for Darwin Information Typing Architecture (DITA) Version 1.3 Errata 01 (csd01 & csprd01)
Date: Thu, 12 May 2016 01:28:44 -0400
From: Paul Knight <paul.knight@oasis-open.org>
To: DITA TC <dita@lists.oasis-open.org>


Per the TC's submission request [1], please find attached two ZIP files with the model documents for: 
Darwin Information Typing Architecture (DITA) Version 1.3 Errata 01 (csd01 & csprd01)
WP-abbrev: dita

****** begin special DITA information ******
These model documents (in .DOCX format) demonstrate the expected appearance of the display formats (HTML and PDF) of the "front matter" of the CSD01 and CSPRD01 levels of DITA v1.3 Errata 01.

For each of CSD01 and CSPRD01:
Note that there is a template for a single "Errata listing" document which will contain a consolidated list of all of the Errata items for all of the Parts, and also a "complete" subdirectory containing all of the Parts, in which you will include (with appropriate change markings) the modified text for each Part. Text that has been removed should be struck-through, while added text should be clearly identifiable  with a text color different from existing text. A useful example showing change markings can be found at [8].  In addition, one possible format for the "Errata listing" document can be found at [9].

- for the PDF version, please set the "title" property to match the actual main title of each document, such as "Darwin Information Typing Architecture (DITA) Version 1.3 Errata 01", if possible.  Note that each of the Parts has an extended title like "Darwin Information Typing Architecture (DITA) Version 1.3. Part 1: Base Edition Plus Errata 01".

As a working approach for the initial publication, please send the final draft HTML and PDF to us (Chet & Paul) for review before the TC holds an approval ballot, to avoid having to repeat the approval ballot.

Some of the usual "boilerplate" instructions below may not apply...
****** end special DITA information ******

When the TC first votes [6] to publish this Work Product in the OASIS Library, we expect it to be published at:
The permanent "Latest version" URI will be:

Please let me know if anything here fails to meet your expectations.
Further revisions to this Work Product must be maintained in Working Drafts, following procedures detailed in the OASIS TC Administration How-to Guide [2].
Working Drafts should be made available by uploading the document(s) to the TC's Kavi document repository, or (provisionally/temporarily) to the TC's Subversion (SVN) repository, if SVN has been activated for your TC [3].  TCs are encouraged to use ZIP packaging when the WD releases contain multiple files (and directories).

For each WD revision, you will need to:
1) increment the Working Draft revision (number) from 01 to 02, 03, 04 etc., as successive Working Drafts are produced; the revision number needs to be updated at the top of the document in the stage identifier (Working Draft ##) and in the document identifier within the page footer.

2) supply the relevant publication/release/upload date for each successive Working Draft instance, using the  prescribed date format: DD Month YYYY; the date needs to be updated at the top of the document (just below the stage identifier, Working Draft ##) and in the page footer.

3) provide suitable text for a document Abstract, updating this summary with successive revisions to provide an accurate description of the subject matter, goals, scope, etc.

4) keep the Acknowledgments (Appendix A) and Revision History (Appendix C) up-to-date with each WD revision.

5) consult the OASIS Naming Directives document when creating new artifacts that may be part of the Work Product (e.g., image files, XML schemas), observing the rules for name characters in files and proposed directories, and for proposed URIs/namespaces [4].

6) examine the instructions for construction of XML Namespace Identifiers (namespace URIs) and Namespace Documents [5] if your specification declares one or more XML namespaces or other namespace-related identifiers for (e.g.,) link relations, named properties, functions, dialects, faults, actions, or any named message types.  All such identifiers, if HTTP-scheme, must begin with: http://docs.oasis-open.org/[tc-shortname]/ns/xxxx

When the TC votes [6] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [7].  

Upon receipt of this form, the TC Administrator will QC and process the Work Product for official publication in the OASIS Library (http://docs.oasis-open.org/) as a Committee Draft, including addition of the requisite cover page metadata and other boilerplate information.

=========== References:
[2] Developing Committee Specifications and Notes
    Starting a Working Draft
[3] SVN Version control, via Tools
[4] OASIS Naming Directives
[5] OASIS Naming Directives - Namespace Identifiers and Namespace Documents
[6] Approval of a WD as a CD (CSD or CND)
[7] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request
[9] Example of Errata listing - single document for all Parts: http://docs.oasis-open.org/odata/odata/v4.0/errata01/csd01/odata-v4.0-errata01-csd01.html

Best wishes,
Paul
--
Paul Knight  - Tel: +1 781-883-1783
OASIS - Advancing open standards for the information society - Document Process Analyst
Identity Ecosystem Steering Group - Framework Management Office



--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 



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