[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Inheritance of attributes through mapref
Hi
Jeff, Conditionalizing
the contents of <title> is one option, however if you try to do this for a
topic in which nothing applies to audience A, a reasonable processor asked to
generate output for audience A would create a topic file with an empty
<title> element, an empty <shortdesc> element, and an empty
<body> element. A reasonable processor would also include a title-free link
in the TOC pointing to that blank topic file. That is what the processor would have
to do unless it was specifically coded to identify blank topics and suppress
them, and I don’t think we want to ask processors to do that. Cheers, Su-Laine From: Ogden, Jeff
[mailto:jogden@ptc.com] 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:su-laine.yeo@justsystems.com] 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 JustSystems Canada, Inc. > 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]