RE: [dita] Question on conditional processing before/after keyspaceconstruction

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

Hi Su-Laine,

> Perhaps what was meant was, "Consequently, a processor should
> produce different effective bindings for the same map if there are
> key definitions that should be filtered out based on their select
> attributes." Is that the intended meaning? Or does the spec really
> intend to say that some processors should give different results
> from other processors, given the same inputs?

I don't think that's what is meant. This comes down to the fact that, from
DITA 1.0, the specification has not defined an order for processing. Thus,
two independent, valid implementations may provide a different processing
order -- such as filtering, then conref, or vice versa. There are
situations where this can give different results.

Keyref came about much later of course, but if we mandate that keys are
evaluated before or after filtering, then there is a domino effect that
implies an order in other processing steps. Mandating that would, in
effect, invalidate DITA implementations that chose a different order. Thus
the sentence you quoted, which I understand to mean - if you filter out key
definitions before you evaluate all of your keys, then you may get
different results than if you establish keys and then filter.

Does that make sense?

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

"Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote on 02/08/2011 05:23:27
PM:

> From: "Su-Laine Yeo" <su-laine.yeo@justsystems.com>
> To: "dita" <dita@lists.oasis-open.org>
> Date: 02/08/2011 05:27 PM
> Subject: RE: [dita] Question on conditional processing before/after
> keyspace construction
>
> Thanks Kris. Eliot's answer to my question was "no" and yours is
> "yes," so people are hearing different messages in the spec.
>
> The part of Kris's quote that jumps out at me is "Consequently,
> different processors might produce different effective bindings for
> the same map when there are key definitions that might be filtered
> out based on their select attributes."
>
> Perhaps what was meant was, "Consequently, a processor should
> produce different effective bindings for the same map if there are
> key definitions that should be filtered out based on their select
> attributes." Is that the intended meaning? Or does the spec really
> intend to say that some processors should give different results
> from other processors, given the same inputs?
>
> Cheers,
> Su-Laine
>
>
>
> From: Kristen Eberlein [mailto:keberlein@sdl.com]
> Sent: Tue 2/8/2011 1:56 PM
> To: Su-Laine Yeo; dita
> Subject: RE: [dita] Question on conditional processing before/after
> keyspace construction

> Yes, this is true according to the DITA 1.2 spec. See http://
> docs.oasis-open.org/dita/v1.2/os/spec/archSpec/overview_of_keys.html and
>
http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/examples_of_keys.html
> for more information. I’ll copy the relevant text below.
> Keys and conditional processing
> The effective keys for a map might be affected by conditional
> processing (filtering). Processors should perform conditional
> processing before determining effective key definitions. However,
processors
> may determine effective key bindings before filtering. Consequently,
> different processors might produce different effective bindings for
> the same map when there are key definitions that might be filtered
> out based on their select attributes.
> If filtering is not done first, the same root map may result in
> different effective key spaces for different sets of conditions. For
> processors that provide sets of available keys within an information
> set, such as authoring support systems, keys may need to be
> associated with the conditions specified on their key definitions.
> For example, given a map that defines the key "os-name" twice with
> different conditions, an author may need to know both that the key
> has two possible bindings within the key space and what the
> conditions are under which those bindings are effective. It also
> means that processors might need both a root map and a set of active
> conditions (for example, a DITAVAL document) in order to correctly
> determine the effective key space.
>
> Duplicate definitions with different conditions:
> <map domains="(map mapgroup-d)">
>   ...
>   <keydef keys="file-chooser-dialog"
>     href="topics/ref/file-chooser-osx.dita"
>     platform="osx"
>   />
>   <keydef keys="file-chooser-dialog"
>     href="topics/tasks/file-chooser-win7.dita"
>     platform="windows7"
>   />
>   ...
> </map>
> In this example, both key definitions use the @platform metadata
> attribute to indicate that they apply to different operating system
> platforms. In this case, the effective key definition is determined
> not just by the order in which the definitions occur but whether the
> active value of @platform is "osx" or "windows7" when the key space
> is determined or the key is resolved. In this case both key definitions
are
> potentially effective because they have distinct values for
> conditional attributes. Note that if no active value is specified
> for the @platform condition when determining the effective keys,
> then both of the definitions are effective and thus the first one in
> document order is the effective definition.
> If the DITA value configuration were defined such that the default
> behavior is "exclude" rather than the normal default of "include",
> then neither definition would be effective and the key would be
> undefined. That case can be avoided by specifying an unconditional
> key definition after any conditional key definitions, e.g.:
> <map domains="(map mapgroup-d)">
>   ...
>   <keydef keys="file-chooser-dialog"
>     href="topics/ref/file-chooser-osx.dita"
>     platform="osx"
>   />
>   <keydef keys="file-chooser-dialog"
>     href="topics/tasks/file-chooser-win7.dita"
>     platform="windows7"
>   />
>   <keydef keys="file-chooser-dialog"
>     href="topics/tasks/file-chooser-generic.dita"
>   />
>   ...
> </map>
> In this case, with an explicitly-configured default behavior of
> "exclude", if no active value for the platform condition is
> specified, the third definition will be the effective definition,
> binding the key "file-chooser-dialog" to the topic
file-chooser-generic.dita.
>
> Best regards,
> Kris
> Kristen James Eberlein l DITA Architect and Technical Specialist l
> SDL Structured Content Technologies Division l (t) + 1 (919) 682-2290 l
> keberlein@sdl.com
> [image removed]
> www.sdl.com/innovate
> Please consider the environment before printing this e-mail
>
>
>
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Tuesday, February 08, 2011 4:12 PM
> To: dita
> Subject: [dita] Question on conditional processing before/after
> keyspace construction
>
> Hi everyone,
>
> The Understanding Keys and Key Spaces document seems to say that
> output of an information set might differ depending on whether
> conditional processing is applied before or after key space
> construction. Is this true? If it is, can anyone provide an example?
>
> Cheers,
> Su-Laine
>
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 1 (778) 327-6356
> syeo@justsystems.com
>
>  [attachment "image001.jpg" deleted by Robert D Anderson/Rochester/IBM]