OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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?

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]