Re: [dita] History Question: Why does <data> not include <cite>?

[ekimber <ekimber@reallysi.com>]

On 9/2/09 12:18 PM, "Erik Hennum" <ehennum@us.ibm.com> wrote:

> 
> Hi, Eliot:
> 
> I believe the thought was that the <data> element should provide
> extensibility for properties attached to content in the flow.  The concern
> about adding content elements was the risk of abuse -- using data as a
> method of adding content to the flow rather than properties of the content
> in the flow.
> 
> With that in mind, <data> itself can refer to resources relevant to the
> topic or part of the body flow within the topic.  The <ph> element can
> provide a description about the related resource.  But, it seems a little
> odd to embed a link in a description when the resource is identified by the
> <data> element.
> 
> 
> With that as background, maybe you could provide an example that makes the
> use case clear?

One use case I have is for a magazine article that is either an excerpt from
or related to another publication, what this publisher calls a "disclaimer",
e.g.:

"World-Class Selling: New Sales Competencies‹by Brian Lambert, Tim Ohai, and
Eric Kerkhoff‹is available from XXXX Press for $299 ($199 for XXXX members)
and includes the entire competency dictionary and seven tools for use in
your organization. To learn more, please visit
www.salestrainingdrivers.org/worldclass. For more information on the
Competency Model, email blambert@xxxx.org"

This information is relating the the publication <cite>World-Class Selling:
New Sales Competencies</cite> to the article and also providing additional
information.

This is metadata for the article as a whole, not metadata for a specific
component of the article content.

In a print presentation of the article this information is presented after
the main body of the article (including any nested topics) and is clearly
not part of the main flow of the article content (that is, it doesn't
contribute directly to the narrative of the article itself).

In an HTML presentation, this information would either not be presented at
all or provided in some other out-of-line way.

Given your explanation above, my reaction would be that trying to prevent
abuse by limiting the content model of <data> is understandable but
misguided, because it can't actually prevent the abuse and prevents
legitimate use cases.

In particular, in the context of Publishing (and, I would guess, business
documents), the content of metadata may be as rich as the content of the
topic itself. The distinction is metadata/not metadata, not
content/non-content. There is also the issue of simplicity and directness of
implementation vs. require a high degree of sophistication of data
structuring just to achieve a simple presentation requirement (e.g.,
rendering the disclaimer statement after the presentation of the article
itself).

For example, in the case of this disclaimer, I could break it down into its
individual pieces and capture each of those as discrete <data> elements and
then implement processing to reconstitute them into the original narrative
paragraph. But that level of expense and complexity is entirely unjustified
by the actual value of the metadata--the individual pieces would almost
never be useful individually, so it's just adding cost in this case,
especially when you consider that the content will almost certainly not be
authored as DITA XML initially.

Or said another way: at its basic level of generality, DITA has no choice
but to trust architects and authors to do the right thing. Any attempt to
legislate morality will, almost without exception, limit the full usability
of the standard. We saw that with tasks and we're seeing it here.

In addition, the new constraint mechanism means that designers can impose
constraints they feel are important to impose. That means that there is less
justification for imposing arbitrary constraints at the most general level
of content. 

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>