Re: [dita-s1000d-discuss] Decision time: DITA or S1000D?

[Scott Hudson <scott.hudson@flatironssolutions.com>]

Hi Joel,

thank you for your comments! I certainly agree that there are situations 
where S1000D may be more appropriate, likewise with DITA.

This discussion list is really intended to address the situation where 
you might want/need to use both standards, and how to interoperate 
content between them.

You mention that:

"S1000D is not the most elegant solution for documenting
software products. If you think that DITA alone is not enough to support
the documentation needs of the on-board software, consider creating a DITA
specialization using S1000D element names and semantics."

and I think it would be a great opportunity for members of both standards to cooperatively create such a specialization. I would not recommend that individual users create the specializations on an ad hoc basis. I would prefer to see an agreed upon best practice provided jointly from the standards organizations.


Best regards,

--Scott

Joel Amoussou wrote:
> Hi All
>
> Let’s look at the DITA/S1000D debate from the perspective of one important
> stakeholder: the user. You are a technical writer, content publisher, or a
> publications manager. You work for an aircraft manufacturer. Your mandate
> is to produce maintenance and operation documentation for a new aircraft
> project. Should you use S1000D, DITA, or both?
>
> Use S1000D to document the airframe, engine, components, and supporting
> equipments. Do not try to create DITA specializations for these subjects.
> Like DITA, S1000D support the following concepts:
>
> 1.Topic-driven information design (data modules)
>
> 2.Extensive metadata facility (IDSTATUS and Dublin Core)
>
> 3.Information maps (publication modules)
>
> 4.Reuse (Common Source Database).
>
> The design of S1000D is also well informed by a century of efforts to
> document aviation and military hardware. The only significant difference
> between S1000D and DITA is that S1000D lacks an extensibility mechanism.
> DITA refers to extensibility as specialization. However, i do not belive
> that the DITA specialization mechanism is the best extensibility mechanism
> available today (more on that later).
>
> If you also need to document the user interface (UI) and application
> programming interface (API) for an on-board software, use DITA. Note that
> this is subject to contract data requirements, particularly for defense
> contracts that sometimes dictate the XML vocabulary to be used for
> documentation deliverables. DITA already has specializations for the
> software, user interface, and programming domains. This by no mean implies
> that DITA is only good for software documentation.
>
> Although the S1000D specification provides an SNS for software projects
> (chapter 8.3.8), S1000D is not the most elegant solution for documenting
> software products. If you think that DITA alone is not enough to support
> the documentation needs of the on-board software, consider creating a DITA
> specialization using S1000D element names and semantics. This will greatly
> simplify round-tripping transforms in the future if necessary. These DITA
> specializations should be created by users on an ad hoc manner as opposed
> to some DITA S1000D Subcommittee. However the OASIS DITA TC can issue
> general high level guidelines for creating interoperable specializations
> for S1000D.
>
> Your S1000D publications modules and data modules can link to DITA maps
> and topics using the <reftp> element. DITA should also support the ability
> to link from a DITA topic or map to an S1000D data module or publication
> module.
>
> The solution to this use case is consistent with the approach of using the
> right tool for the job at hand.
>
> Best regards,
>
> Joel Amoussou
> http://www.efasoft.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-s1000d-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-s1000d-discuss-help@lists.oasis-open.org
>
>   

begin:vcard
fn:Scott Hudson
n:Hudson;Scott
org:Flatirons Solutions
adr:Suite 200;;4747 Table Mesa Drive ;Boulder;CO;80305;USA
email;internet:scott.hudson@flatironssolutions.com
title:Consultant
tel;work:303-542-2146
tel;fax:303-544-0522
tel;cell:303-332-1883
url:http://www.flatironssolutions.com
version:2.1
end:vcard