Re: [dita] DITA Semantics Potentially Affected by Filtering

[Robert D Anderson <robander@us.ibm.com>]

This is more or less what I expected, after a history of switching some of
the steps around before the order became settled in the DITA Open Toolkit.
I expect you'll find that other steps interact with each other as well
(resolving conref and then pulling text into <xref>, and vice versa). I
think that Paul Prescod was the first to raise the idea of a separate
processing spec several years ago, in order to figure out how all of these
items interact, but nobody has really taken that forward. That's the main
reason I don't think we can add MUST behaviors with regards to previously
existing behaviors - I'm relatively sure it would cause 1.1 compliant tools
to fail.

Because keyref is a new behavior, I think it's acceptable for the spec to
mandate a processing order for that item (though not if it says "keyref is
evaluated in between filtering and conref", which would thus mandate
filtering before conref). However, at this point I haven't made up my mind
on what sort of statement should be there.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

ekimber <ekimber@reallysi.com> wrote on 11/03/2009 11:36:01 AM:

> ekimber <ekimber@reallysi.com>
> 11/03/2009 11:36 AM
>
> To
>
> dita <dita@lists.oasis-open.org>
>
> cc
>
> Subject
>
> [dita] DITA Semantics Potentially Affected by Filtering
>
> Here is my attempt to analyze the effect of filtering on DITA processing
> semantics. Note that the Open Toolkit does filtering before any other
> processing, so it always reflects the results of applying filtering
first.
>
> My initial instinct was that only keyspace construction was affected by
> application of filtering. It appears I was completely wrong. My analysis,
> given below, is that every significant processing semantic will give
> significantly different results when filtering is applied first and when
it
> is not.
>
> I think this is a complete list of relevant processing semantics. Note
that
> I'm only considering processing that is intended to have invariant
results
> (that is, it's not a rendition option but a DITA-defined semantic).
>
> 1. Keyref
>
> A given key may be the effective key when filtering is applied and not
the
> effective key when filtering is not applied.
>
> * Filtering is significant
>
> 2. Content reference
>
> When "-dita-use-conref-target" is *not* used, a referencing element will
be
> filtered out before or after conref resolution, because its applicability
is
> not modified.
>
> When "-dita-use-conref-target" *is* used and the referenced element has a
> different applicability, the referencing element can filtered differently
> following conref resolution than before. If the referenced element is
> filtered out, the effect of the conref if filtering is applied before
> resolution is that the content reference cannot be resolved and the
> referencing element is unmodified in the resolved result. If filtering is
> applied after conref resolution, then the resolved result is filtered
out,
> resulting in no element at all in the resolved and filtered result.
>
> * Filtering is significant
>
> 3. XRef resolution
>
> If an xref is resolved to its target before filtering and the target is
> subsequently filtered out, the xref would be to a non-existent target but
> might reflect properties of the target (e.g., the xref link text might
> reflect the target's title). If the xref is resolved after filtering is
> applied and the target is filtered out, the xref is to a non-existent
> target, which will can result in a different link text. The rendition
effect
> for the navigation link will be the same: the link cannot be navigated
> because the target doesn't exist in the rendered result.
>
> * Filtering is significant for link text, not significant for link
> navigation
>
> 4. Map metadata propagation
>
> Filtering applied before propagation could definitely result in different
> effective values than if it is applied after. In particular, elements
> filtered out would never contribute to propagation.
>
> * Filtering is significant
>
> 5. Topicref resolution
>
> Same analysis as for xref: resolution of topicrefs before filtering could
> result in use of topic-provided navigation titles or metadata that would
not
> be used if the target topic was filtered out before resolution. In both
> cases, the topicref as rendered would be to a missing topic.
>
> * Filtering is significant
>
> 6. Chunking
>
> A topicref subsequently filtered out that generates chunks would create
> chunks in the output if chunk processing is done before filtering but
since
> the topicref would then be filtered out, the chunks would not be
referenced.
>
> * Filtering is significant
>
> 7. @copy-to
>
> If copy-to processing is done before filtering, two topicrefs, only one
of
> which is applicable, could specify the same copy-to target, leading to a
> conflict and a potential ambiguity about which governs. If the topicrefs
are
> filtered before copy-to processing, the conflict cannot occur.
>
> NOTE: The current spec does not say what happens when two topicrefs
specify
> the same copy-to value.
>
> * Filtering is significant
>
> Cheers,
>
> Eliot
>
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> office: 610.631.6770 | cell: 512.554.9368
> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
> <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>

>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>