[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Inheritance of attributes through mapref
Thanks for providing the relevant section of the 1.1 spec. I think the TC should re-examine whether the spec might be wrong. I agree that this thread didn’t start out with the intention of revisiting the 1.1 map-to-topic cascading rules, but if they’re wrong we should fix them before copying the problem over to the map-to-map cascading rules.
Having said that, I thought more about the example I gave, and I think the conclusion I first reached is not quite right either. If there is a difference between the conditional values on a topicref and the values on an element in the referenced topic, the processor should have different rules depending on whether the element has values for that attribute or not. In the example, if topic 3 contains an element with no “audience” attribute, that element should be processed as if it inherits audience values from the topicref. However, if topic 3 contains an element with an “audience” attribute, that element should be processed as if its audience values are the intersection between the local values and any audience values on the topicref.
When I think about this issue abstractly, it also seems logicially wrong to ask processors to add conditional attribute values that are set at different levels. The way that conditional attributes work is that when you specify what audiences an element is for, you are implicitly saying that it is not for any other audience. E.g. when you say that audience = “c”, you are saying that the audience is not B or A.
Here is a second use case, which is an extension of the first but illuminates a few more issues: You are creating a document for three audiences, A, B, and C. The map includes:
1) a topic that is common to all audiences
2) a topic in which the entire topic is for audience A only
3) a topic that does not apply to A at all, and contains some elements that apply only to B and some elements that apply only to C
4) a topicref pointing to a submap that includes the following topics:
- 4.1) a topic that applies to B and C only
- 4.2) a topic for B only
- 4.3) a topic that contains some elements that apply only to B and some elements that apply only to C
If generating output for audience A, you will want to include topic 1 and 2. Topic 3 and submap 4 should not appear.
If generating output for audience B, you will want the TOC to include topic 1, unconditional and B-only elements from topic 3, topic 4.1, topic 4.2, and unconditional and B-only elements from topic 4.3.
There are four ways to indicate that topic 4.1 applies to B and C only:
- mark topicref 4.1 as having audience =”b c”
- mark topic 4.1 as having audience =”b c”
- mark submap 4 as having audience =”b c”
- mark topicref 4 as having audience =”b c”. This is useful because it is possible that the author of submap 4 knew that audiences B and C existed, but was unaware of the existence of audience A, and so did not indicate anywhere within the submap or its topics that 4.1 was a conditional topic. In this case, the author of the parent map should set “audience=”b c” on the topicref that points to submap 4.
Using any of these four methods, the processor will give desired results if it follows the following rules for both map-to-topic and map-to-map cascading:
- An element inherits conditional attribute values if it has no local values for that attribute.
- An element is processed as if it has the intersection of local and inherited attribute values, if any local values exist for that attribute.
That’s all my brain can handle today :)
JustSystems Canada, Inc.
Su-Laine, thanks for providing a concrete use case.
Is the use case just a single map and cascading of attribute properties from that map to the topics? It isn’t talking about map to map cascading is it?
I thought that the map to topic case was already settled in the DITA 1.1 specification and we were just talking about cascading in the map to map case. Am I mistaken about that?
Here is what the section “Topic properties in topics and maps” in the DITA 1.1 Architecture Spec. says:
The properties of a topic (including metadata attributes and metadata elements) can be specified in the
topic itself or in references to the topic within maps.
. . .
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.
And I’m arguing that for simplicity’s sake we should follow the same rules for the map to map case as already exist for the map to topic case.