MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Groups - DITA 1.1 #9 (2): element for properties and embeddeddata (Issue9.html) modified
Hi, Esteemed TC:
Bruce and I had an offline conversation about the <data> element, from which I'd bring forward a few clarifications. These clarifications don't require subsequent changes to proposal 9.
The DITA outputclass attribute can be used as a workaround for subclassing (similar to the HTML class attribute) on almost all elements by users for whom specialization isn't possible. We might want to give that point more prominent visibility in the specification.
The pattern-matching requirement in Bruce's mail below would be statisfied by the DITA 1.1 keyref feature (assuming indirect reference by key is allowed in the conref attribute).
Properties can indicate their subjects through nesting. (In the following example, <attributedLongQuote> is specialized from the base DITA <lq> element and <attribution> and its contents are specialized from <data>.)
<attributedLongQuote>
<attribution>
<attributionAuthor>...</attributionAuthor>
<attributionTitle>...</attributionTitle>
<attributionPublisher>...</attributionPublisher>
</attribution>
All that is necessary for the triumph of evil is that good men do nothing.
</attributedLongQuote>
Properties can also indicate their subjects through explicit references. (In the following example, <attribution> and its contents are specialized from <data>.)
<concept id="pundit">
<prolog>
...
<attribution about-href=""#pundit/triumph">
Erik Hennum/Oakland/IBM
09/07/2005 08:02 AM
|
|
Hi, Bruce:
Good issues for probing the design -- I've some responses.
1. User-defined data
Like the existing <state> element, the <data> element provides a name attribute for this purpose. In fact, it's probably a best practice for specializers to provide a default name and offer the users of their specialization the ability to add user-defined precision to their specialization.
<data name="product-family" value="Everything Anyone Could Want">
<data name="product" value="This Most Valuable Product">
<data name="model" value="At Your Price Point">
<data name="configuration" value="With Your Features">
<data name="feature">Feature One</data>
<data name="feature">Feature Two</data>
</data></data></data></data>
<data name="recipe">
<data name="ingredients">
<data name="ingredient">Any starch</data>
<data name="ingredient">Any topping</data>
</data>
<data name="item served">Food consisting of starch with topping</data>
</data>
In the examples, I've moved the parent values into the value attribute because, as Dana pointed out in correspondence, the purpose of the <data> element is to arrange atomic values in structures. Thus, the best practice for specializers and users is to avoid mixed content models.
Of course, as with any pattern that isn't encoded by the markup, the consistency of the instances of the product and recipe data structures depends entirely on the diligence of the writers. Better than nothing, and the patterns could be validated with Schematron (though that would be about as complex as specialization with less benefit).
The outputclass (aka, the poor man's specialization) can also be used for sharing a semantic across multiple instances, but I think you'd want the ability to apply the same outputclass to multiple named values, so it wouldn't specify user-defined types for data.
2. Referring to instances
The <data> element would use the same referencing mechanisms (including the new keyref) as any other DITA element to become the target or source of a refererence:
<topic id="thisTopic">
...
<prolog>
<author id="topicAuthor">Charles Schulz</author>
<data name="profession" abouthref=""#thisTopic/topicAuthor">cartoonist</data>