On 08/19/2016 05:55 PM, David Goss wrote:
Thanks so much for the response.
XMLmind DITA Converter simply works like that
Was there perceived advantage to processing keys first, then filters when
developing the ditac?
I'm curious if there was a technical reason for that decision, or if it
just happened that way because the spec wasn't originally clear (I don't
think the "should" language was in the 1.0 or 1.1 specs) and that's just
how it ended up. In my head, I don't see an advantage to processing keys
first, but there might be another way of looking at it that I'm not seeing.
Simplicity. Divide a large, very complex, problem into several smaller,
hence simpler, problems. For ditac, the first smaller and simpler
problem to be solved is: determine effective key definitions.
Call this behavior a bug if you want. We do not plan to change this
behavior (or to parametrize it) in ditac v2; may be in v3.
I mean, may be after carefully re-reading the DITA 1.3 spec in order to
implement this version of the spec, we'll have to change (or to
parametrize) current behavior. Full DITA 1.3 support is planned for this
year.
That makes perfect sense.
I definitely do not consider a bug, since the spec says "should" when
talking about processing order. The language hasn't changed much in this
regard in the 1.3 spec:
http://docs.oasis-open.org/dita/dita/v1.3/os/part2-tech-content/archSpec/base/processing-key-references-general.html#processing_key_references
Yes, this is more or less allowed by the DITA 1.3 spec:
---
Processors SHOULD[1] perform conditional processing before determining
the effective key definitions. However, processors might[2] determine
effective key definitions before filtering.
---
Ditac implements [2].
I haven't done exhaustive review yet, but at first glance, this really
doesn't cause any issues other than missing key messages for content that
is filtered out. There's probably a scenario where you would end up with
different content. It's probably affecting processing time, but the ditac
is so fast I'm not noticing or caring.
Moreover, with the following, quite common (where key "some-key" exists
and has a value whatever the filter being used), variation of your DITA
sample, there is no warning at all:
---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map id="map">
<title>Test Map</title>
<topicref href="topic-a.dita" product="product-a"/>
<topicref href="topic-b.dita" product="product-b"/>
<keydef keys="some-key" product="product-a">
<topicmeta>
<keywords>
<keyword>AAA</keyword>
</keywords>
</topicmeta>
</keydef>
<keydef keys="some-key" product="product-b">
<topicmeta>
<keywords>
<keyword>Test</keyword>
</keywords>
</topicmeta>
</keydef>
</map>
---
--
XMLmind DITA Converter Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/ditac-support
