Among other things Su-Laine Yeo wrote:
I
have thought of trying to get the desired behavior by explicitly
conditionalizing all of the elements in topic 3 instead of putting conditions
on the topicref, however this is not feasible because you cannot conditionalize
element types such as <title>.
Couldn’t you conditionalize the
contents of a <title> rather than the <title> itself? Something
like this:
<title>
<ph audience=”a”>A
people are much smarter than B people</ph>
<ph audience=”b”>B
people are much smarter than A people</ph>
</title>
This isn’t an argument for or against
merging or overriding values that cascade from maps to maps or from maps to
topics, just an observation.
-Jeff
From: Su-Laine Yeo
[mailto:]
Sent: Tuesday, April 14, 2009 2:45
PM
To: dita
Subject: RE: [dita] Inheritance of
attributes through mapref
Regarding merging
vs. overriding for conditional attributes, let’s consider the following
example: 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 which
does not apply to A at all, and 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 should not
appear at all, not even in the TOC.
If generating output
for audience B, you will want the TOC to include topic 1 and topic 3. Topic 3
should include any unconditional elements, include the elements that apply to
B, and exclude the elements that apply only to C.
Currently the OT
gives the desired behaviour if you set audience=”a” on the topicref
to topic 2 and audience=”b c” on the topicref to topic 3. If we
were to say that audience attribute values on a topicref are added to the
conditional attributes within the target topic, you would not get the desired
behaviour in this case, because when generating output for audience B, you
would get all the content for audience C in topic 3. I have thought of trying
to get the desired behaviour by explicitly conditionalizing all of the elements
in topic 3 instead of putting conditions on the topicref, however this is not
feasible because you cannot conditionalize element types such as <title>.
So I think this
particular example supports a rule that conditional attribute values should be
processed as the intersection as of the values on the topicref and the values
on the further down the hierarchy. I think this is the rule which is actually
implemented in the current OT.
Regards,
Su-Laine
Su-Laine Yeo
Interaction Design Specialist
JustSystems
Canada, Inc.
Office: 778-327-6356
www.justsystems.com
> The two open questions are:
> 1) What about attributes like @audience, which take multiple
values? If my
> map reference has audience="a b", and the map has
audience="c", does "a b"
> override "c", or does this result in "a b c"?
If the latter, we will need
> to come up with an authoritative list of which attributes act this
way (as
> opposed to the override behavior of @toc and @linking).
Don’t we already have a list for the
later case (merge)? If an attribute value cascades and the attribute
allows multiple values then. it merges. If an attribute value cascades
and the attribute does not allow multiple values. it overrides.
My goal here is just to make the rules for
map to map cascading as much like the rules for other cascading as possible
because that is more consistent and therefore easier to remember. And
while the DITA 1.1 spec. didn’t talk about map to map cascading
explicitly, when it did talk about cascading more generally it talked about
merging multi-valued attributes and overriding single values attributes. So it
just seem unnec3essairly complicated to introduce a new case. Note too
that this question is about general cascading and that there are separate rules
for conref behavior.
