Hi, Scott, Eliot, John, and Indi:
Indi, I'm copying you directly with these comments because I know you have wrestled with retrofitting existing vocabularies and might have some experience to share.
I'd note that retrofitting is likely to have limits and costs.
You could certainly treat the entire existing S1000D element set as a single base module (equivalent to the DITA topic module). That would give you the ability to derive new elements from the existing S1000D elements and to generalize from these specialized elements back to the existing S1000D elements.
As I read S1000D, there's an intent for modularity. A more ambitious retrofitting effort would be to attempt to refactor the existing S1000D element set into type modules and, possibly, define specialization relationships between the existing S1000D elements. Because a specialized element has to be a structural subset of the base element (including attributes), whether that's possible depends entirely on the existing element definitions. Whether this refactoring can support content with topic granularity, again, depends entirely on the definition of existing model. That is, merely adding class attributes can't introduce consistency between semantically related elements nor topic granularity into models with continuous discourse.
Even if you could retrofit an existing vocabulary with a topic architecture, however, you'd lose reuse and interoperability with the standard DITA types. As new types are added to the DITA type hierarchy, those types would become available to DITA adopters but not to the retrofitted S1000D users. Similarly, DITA adopters could exchange content through DITA generalization, but S1000D users would have to use a custom transform that might have areas with poor interchange. As is well established in Object Oriented systems, a common type hierarchy with a single base has tremendous value for interoperability.
Thus, from a technical perspective, the best solution would be to rework the S1000D elements as needed to graft S1000D type modules onto the DITA type hierarchy. The result would support content that's completely DITA interoperable but looks a lot like S1000D documents and provide a relatively good transform target (because of similar semantics and structure). That approach would have significant long-term benefits. Before the S1000D community could embrace that approach, someone would have prototype the S1000D modules to demonstrate the possibilities.
More generally, the DITA TC should recommend as a preferred approach that human-readable topic content be modelled on a single type hierarchy. Of course, other kinds of content (for instance, invoice data) would be a distinct type hierarchy.
Thanks,
Erik Hennum
Eliot Kimber <>
Eliot Kimber <>
08/23/2004 02:42 PM
Please respond to
ekimber
To
"Tsao, Scott" <>
cc
, , John Hunt/Cambridge/IBM@Lotus
Subject
Re: [dita] Re: Comparison between DITA and S1000D
Tsao, Scott wrote:
> As John said: "Modeling all of the details of S1000D with DITA topic and
> domain specializations would be a
> large task," are you suggesting that one could potentially reap the
> benefits of the second without doing
> the first?
>
> Am I interpreting your comments correctly?
Yes. One could get all the benefits of a generic and powerful
specialization mechanism independent of the DITA vocabulary.
S1000D stands as typical example of many existing XML applications that
are both closely adapted to a particular task (e.g., aircraft
maintenance) and that reflect a long history of development and practice
that has informed the details of the application: element type and
attribute names, content model patterns, linking constructs, and so on.
In addition, it almost certainly has a large body of supporting
infrastructure tightly bound to those names. Because all of this work
was done before DITA was widely known it is highly likely that many
aspects of the application will not be directly consistent with the DITA
constraints.
Thus while it is almost certainly the case that S1000D could be replaced
with an equivalent DITA-based application, largely because all technical
documentation is essentially the same. But whether it would actually be
of advantage to the S1000D community to do so is an open question.
But it is also clear that *every* community of non-trivial size that
tries to do XML-based interchange needs a specialization mechanism
exactly like the one DITA defines. Therefore it is almost certainly the
case that *every XML application currently in use* would benefit from
adding a means to do controlled specialization. Therefore it is almost
certainly the case that the S1000D application (and more importantly,
the community of S1000D users) would benefit from being able to do
controlled specialization.
One way to look at this is:
1. What is the likelihood that S1000D data would need to be interchanged
or processed outside of an S1000D context but within a DITA-based context?
2. In the case that such interchange is required, is doing an
S1000D-to-DITA transform sufficient? If the interchange is does not
involve feedback (no round tripping required) then transform-based
interchange is indicated because it is clearly much cheaper to implement
a transform than to re-engineer an entire community. If the interchange
requires round tripping, then the cost of doing transform-based round
tripping must be evaluated against the cost of retrofitting the S1000D
community to a DITA-based S1000D.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
www.innodata-isogen.com
