dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Question about keyref with format="ditamap"
- From: "Robert D Anderson" <robander@us.ibm.com>
- To: DITA TC <dita@lists.oasis-open.org>
- Date: Mon, 13 Apr 2015 16:17:56 -0500
Hi,
I have a question about some language that is in 1.2 and the 1.3 draft. Specifically, the wording is:
A key reference to a topicref element where the linking element specifies a format value of "ditamap" addresses the topicref element itself as though the topicref element had been addressed by ID. In particular, a topicref with a key reference to another topicref and a format value of "ditamap" is a use of the map branch rooted at the referenced topicref. [1]
In 1.2 and draft 1.3, it's hidden below an example, which is probably why I hadn't really thought much about it (it looks like part of the simple example). I'm guessing that's true of most other readers. However, it's actually setting out a normative rule that isn't mentioned anywhere else.
I think the rule means that I can have the following map, and have the first two key references resolve differently:
<topicref keyref="mybranch"/>
<topicref keyref="mybranch" format="ditamap"/>
<topicref keys="mybranch" href=""> <topicref href=""></topicref>
The first topicref with keyref="mybranch" resolves as a reference to someParent.dita -- this is normal resolution for a key.
As I understand the spec, the second topicref works differently because of the format="ditamap" attribute. It is "a use of the map branch rooted at the referenced topicref" -- almost the same as a conref of that branch (not quite the same, because metadata merging between the two is not straightforward).
I don't like this for a few reasons. First - I had to read the language many times to work out what it is saying. Second - I don't find the use intuitive. It seems wrong to have @format on the reference trigger an entirely different resolution. Third - I think that if you want an indirect reference to an entire map branch, the following markup is more in line with other keys:
<topicref keyref="mybranch"/>
<topicref keys="mybranch" href="" format="ditamap"/>
In that case, your key would resolve using normal key processing rules -- pulling in both @href and @format -- after which you end up with a reference to whatever map or whatever branch you need:
<topicref href="" format="ditamap"/>
Once I worked out the meaning of the current rule, I checked with a couple other people, and it surprised them as well. We're not aware of any key processor that would support the resolution described here. So my questions are:
1. Is my interpretation of the rule correct?
2. If so, has anybody ever implemented it, or could anybody see implementing it?
3. If no implementations, can we remove this language, since alternate markup can get the same result?
Thanks -
[1] http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/using_keys_to_address_dita_elements.html
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]