the current version of DITA data model supports several complementary implementation of reusing data.
reuse of topic as complete information object
conref to reuse within fine structure of an information object (useful for common used structures like warnings)
and profiling of information objects.

all of these methods are static, means the reused content cannot be adopted even if life cycle of information requires this (thats what ann rockley called a locked reuse).

if you talk about the life cycle of information this kind of reuse has strong limitation. if you want to "reuse" a use case provided by a analyst / software developer into a task (which would be very common) you have to force the analyst to specify in a way further usage of this use case (information object) can be provided as is.

thats has one major drawback. the analyst must focus on the specification and must provide information in a way the engineering team can work with. if he spend to much time in generalize the information object his skills are "wasted" and overall ROI will not be positive.

on the other hand the information created by the analyst must be adopted for service documentation, training documentation, user documentation.....means the use-case and corresponding topic in user documentation are the "same" information object from an information architectural point of view.

each time the use case changed the associated user documentation task must be adopted or at least approved.

this kind of approach can be perfect supported by a "dynamic reuse" or ann rockley would call it 

"derivative reuse". this means that the content of the information object is copied into the derived information object but there is still a connection to the information provider available. thus connection can be used to provide processing support for "dynamic reuse" e.g. an change notification each time the information provider changed, .....

what needs to be done to introduce dynamic reuse in DITA. a special kind of attribute is required which maintain the link to the information provider. this attribute must be specified (e.g. dynref) as well as the associated elements the attribute is required. similar to conref. the semantic of this reference must be specified as well.

thats simple for a standardization point of view, but provides many advantages. if this is standardized all people working on the processing chain (incl. DITA OT) can provide / improve support for this and somehow in the future most tool vendors implemented support for this.

in my personal point of view this is the missing gap in most information architectures that everything is based on static reuse. thus the life cycle of information objects are limited and therefore the usage of information objects are as well limited.

feedback welcome,

Alex

----

Read more

there are two use cases i'll currently seen in the field of DITA adoption:

1. using reference implementation of DITA OT out-of-the box
   this approach speeds up initial step in adopting topic oriented approaches for creating supported output formats
   
   if you look into existing task / reference / concept specialization you see that those data models are not suitable for each user in each domain and using the dita topic itself lacks of semantic and therefore only recommended in certain use cases.
   
2. using specialization to adopt DITA OT datamodel to user specific needs.
   this is one of the major advantages of DITA in general. beside issues related to information architecture (how to identify "best practices", requirements for specialization that works for me, .....) there is one technical issue you might be thinking of:
   
   "how to verify that a certain datamodel is DITA complaint"
   
   there is currently no way to make sure a "announced DITA complaint DTD / W3C Schema" conforms to what is described in the standard.
   

you might think that this is not a major issue, but the more DITA gets used the more "DITA aliens" are created and no one might ever know if the created content can or cannot be interchanged with other DITA complaint processing chains. even if there are currently still many good reasons to extend a DITA datamodel in a non complaint way you should even get the informed about that to estimate the implact.

because DITA currently lacks of a normative, formal specification this also helps to get more formalize specification in terms of requirements of a DITA complaint datamodel.
based on knowledge and best practices a set of rules should be creating describing the requirements of a datamodel to be announced as DITA complaint. therefore in my point of view it would be useful to create a "validation process" which can be used either:

• to express and validate the rules described in the standard against consistency and feasibility
  thus can be used to also verify extension to the standard in a formal, normative way
  
• to get rid of "validation by example" which is in general not a formal validation but also tricky and error prone

how to get this:

• as a basic infrastructure you need parser create a format independent structure of DTD / W3C Schema
  

  DTDinst (http://www.thaiopensource.com/relaxng/dtdinst/) might be a good infrastructure to provide unique XML representation of the datamodel.

  Read more