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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-s1000d-discuss message

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


Subject: Decision time: DITA or S1000D?


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





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