Good issue -- that should have been addressed.
I can see a case for having both a value and content where the content adds detail about the value, as in:
<availabilityProblem value="intermittent">
<incidentStart value="11:21"/>
<incidentEnd value="12:16"/>
</availabilityProblem>
Of course, another way to express that data would be to bump the value down to a peer of the other content:
<availabilityIncident>
<availabilityProblem value="intermittent"/>
<incidentStart value="11:21"/>
<incidentEnd value="12:16"/>
</availabilityIncident>
But, the first form might express the intent better where the start and end times are just incidental and the problem itself is the salient fact.
There may also be cases where a value attribute could be useful for text content -- again, where the value says something general and the content provides the detail:
<temperature value="centigrade">17.3</temperature>
Of course, the same thing could be expressed as follows:
<temperature>
<temperatureScale value="centigrade"/>
<temperatureMeasurement value="17.3"/>
</temperature>
But that markup might be too heavyweight for some uses.
There may be cases where a designer who is defining a specialized <data> element with a value attribute wants to provide an optional nested <data> element to allow for unknown detail (potentially through specialization).
Could the statement be something along the following lines:
A <data> element should allow both an attribute value and content only where the content adds detail or specificity to the value.
What do you think?
Erik Hennum
ehennum@us.ibm.com
"W. Eliot Kimber" <ekimber@innodata-isogen.com>
