← Prev in month ← Prev in thread
Next in thread → Next in month →

resolving conflicts between attributes and metadata in DITA

From
Oaul Frosso
Date
2006-10-11T13:55:00+00:00
ID
Thread
resolving conflicts between attributes and metadata in DITA
In an attempt to understand better the process of how 
attributes on conref references and targets get "merged", we (mostly Jeff) 
reread the Arch spec with respect to resolving conflicts between attributes in 
DITA and came up with the following set of observations and issues. It appears 
that the spec needs clarification in this area.
 


The DITA 1.1 Architecture 
Specification (9/26) is ambiguous with 
respect to resolving conflicts between map and topic metadata attributes and 
elements.  More often than not conflicts are resolved in favor of the 
referencing element (map over topic for example). What isn’t clear is what 
exactly is a conflict and what it means to resolve a conflict.
 
This is mentioned in several 
different places in the spec:
 
(1) On page 20 in the section 
“Shared metadata elements, and the lockmeta attribute” where it 
says:
 
By default metadata in 
the map supplements or overrides metadata in the topic. 
If the lockmeta 
attribute is set to “no”, then the metadata in the map will not 

take precedence over 
the metadata in the topic, and conflicts will be resolved in favor of the 
topic.
 
(2) On page 21 doesn’t talk about 
conflicts between topics and maps, but seems to be focused on maps. In the 
section on “Inheritance of attributes and metadata” it says:
 
Inheritance is additive 
except where this would cause a conflict. When there is a conflict, 

the value defined 
closest to the topicref takes effect.
 
(3) On Page 26 in the section 
“Common metadata and data elements” it says:
 
            
The same metadata elements are available in both DITA topic types and DITA map 
types. 
This allows the 
metadata assigned to a topic when it is created to be supplemented or 

overridden when the 
topic is included in a collection.
 
(4) On page 27 in the section 
“Metadata qualification elements” it says:
 
            
When metadata is expressed in a map, it supplements any metadata expressed 

in the topics it 
references. When metadata in a map and a topic conflict (for example, 

both define a 
publisher), by default the value in the map takes precedence, on the 

assumption that the 
author of the map has more knowledge of the reusing context 
than the author of the 
topic.
 
(5) And on page 28 toward the end of 
the section “Topic properties in topics and maps” it says:
 
            
If a property is set in both the map and topic, the map properties are additive 
if 
the property (such as 
the audience type) takes a list of values. If, instead, the 
property (such as the 
importance) takes a single value, the map property 
overrides the topic 
property.
 
This last mention (5) is the only one that talks about what to do 
when an element or an attribute accepts a list of values.  Here the context 
is topicref and topics.  What isn’t clear is if this approach applies more 
broadly.  We had been assuming 
that it did and that this was the approach that should be used when resolving 
conflicts between metadata attribute and element values whereever they 
occur.  But after yesterday's TC 
discussion about conflicts having to do with the conref attribute 
and after rereading the spec., we are 
no longer sure.
 
In the other cases, the spec 
talks about conflicts, but doesn’t 
say in detail how they are resolved. We know that conflicts are resolved in 
favor of the map or the topic or in favor of what is defined nearest to the 
topicref. What we don’t know is what it means to have a conflict and what it 
means to resolve a conflict.  Is the existence of the same attribute on two 
elements a conflict?  Is the existence of the same attribute on two 
elements a conflict if in one case the attribute value is an inherited default 
value and the other is an explicit value?  What if the attribute is 
present, but empty or null?  And are conflicts resolved by choosing one of 
the two values or in some cases are they resolved by merging values when an 
attribute allows multiple values?  In the case of merging multi-valued 
attributes, do we just include all of the values or do we need to remove 
conflicting values?  If conflicting values appear in a list, which one 
wins, the first or the last?
← Prev in month ← Prev in thread
Next in thread → Next in month →