[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] History Question: Why does <data> not include <cite>?
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]