[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] DITA Semantics Potentially Affected by Filtering
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]