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. > 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 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. ------ David Goss , Technical Writer Frontier Science | www.fstrf.org 4033 Maple Rd, Amherst, NY 14226 (716) 834-0900 extension 7204 ----- Original Message ----- From: "Hussein Shafie" <[email protected]> To: "goss" <[email protected]> Cc: "ditac-support" <[email protected]> Sent: Thursday, August 18, 2016 1:55:33 PM Subject: Re: [ditac] Issue with keys being resolved before filters On 08/18/2016 04:43 PM, David Goss wrote: > > I'm seeing a lot of warning about unresolved keys when processing filtered > maps. These are caused by keys that are missing because both the topic > causes the warning and the key are filtered out. > > Below is an example. If I process the below using the test.ditaval > specified, I get a missing key for `some-key` in topic-b. Both some-key and > topic-b are filtered out by the filter. This warning isn't really expected > because topic-b shouldn't have been processed in the first place. > > (1) Is this the expected and desired behavior, or is it a bug? XMLmind DITA Converter simply works like that: --- ditac -v -filter test.ditaval -chunk single /tmp/map.html map.ditamap ditac: INFO: Loading "/home/hussein/tmp/filter_order/map.ditamap"... ditac: INFO: Loading the key definitions contained in "/home/hussein/tmp/filter_order/map.ditamap"... ditac: INFO: Loading "/home/hussein/tmp/filter_order/map.ditamap"... ditac: INFO: Simplifying main topic map "/home/hussein/tmp/filter_order/map.ditamap"... ditac: INFO: Simplifying main topic map "/home/hussein/tmp/filter_order/map.ditamap"... ditac: INFO: Loading "/home/hussein/tmp/filter_order/topic-a.dita"... ditac: INFO: Loading "/home/hussein/tmp/filter_order/topic-b.dita"... ditac: WARNING: file:/home/hussein/tmp/filter_order/topic-b.dita:5:54: cannot resolve keyref="some-key" and there is no href fallback attribute ditac: INFO: Processing inclusions in the topics... ditac: INFO: Processing related links in the topics... ditac: INFO: Filtering the topic map... ditac: INFO: Adding attributes and metadata to the topics... ditac: INFO: Filtering the topics... ditac: INFO: Creating title-only topics... ditac: INFO: Adding related links to the topics... ditac: INFO: Determining which files are to contain the topics... ditac: INFO: Processing IDs and links... ditac: INFO: Numbering equations... ditac: INFO: Saving information about preprocessed files to "/tmp/ditac_lists.ditac_lists"... ditac: INFO: Saving preprocessed file "/tmp/map.ditac"... ditac: INFO: Transforming "/tmp/map.ditac" to "/tmp/map.html" using /home/hussein/src/ditac/xsl/xhtml/xhtml.xsl... --- 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. > (2) If expected (if I recall, the spec is ambiguous on when filtering > should happen, which is why the DITA-OT has a filter-stage parameter) That's why we really need to first carefully re-read the DITA 1.3 spec before making any major change. > is there a way to change the order of operations here so that filtering > takes place before resolving keys? Sorry but the answer is no. > > <!-- map.dita --> > <?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-b"> > <topicmeta> > <keywords> > <keyword>Test</keyword> > </keywords> > </topicmeta> > </keydef> > </map> > > <!-- test.ditaval --> > <?xml version="1.0" encoding="utf-8"?> > <val> > <prop action="exclude" att="product" val="product-b"/> > </val> > > <!-- topic-a.dita --> > <?xml version="1.0" encoding="utf-8"?> > <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd"> > <topic id="topic-a"> > <title>Test topic A</title> > </topic> > > <!-- topic-a.dita --> > <?xml version="1.0" encoding="utf-8"?> > <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd"> > <topic id="topic-b"> > <title>Test topic B</title> > <shortdesc>Here's a keyref: <ph keyref="some-key"/></shortdesc> > </topic> > > <!-- warning that appears during processing --> > (10:29 goss:~/test/ditac-ditaval)$ ditac -filter test.ditaval test.pdf > map.ditamap > ditac: WARNING: file:/home/goss/test/ditac-ditaval/topic-b.dita:5:53: > cannot resolve keyref="some-key" and there is no href fallback attribute > > -- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
