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

[Eliot Kimber <ekimber@reallysi.com>]

The wording in the spec is a little awkward. Here the "might" is in the
sense of "when key definitions have select properties *and* those select
properties are used for filtering then it can be the case that, depending on
the active conditions that are set, that you will have different effective
bindings than if a different set of active conditions were to be set." But
just because filtering is applied it doesn't mean the effective key spaces
are *always* different for different sets of conditions.

That is, the effect of filtering may result in a different set of effective
bindings if the filtering happens to make a binding effective that would
otherwise not have been effective because all the bindings that occur before
it for one of its keys got filtered out.

The other language challenge here is the term "different". Here "different"
means "different from the effect of a different *set of conditions*" not
different processors.

*In all cases* the correct key space is 100% deterministic and there should
not be any case where two different processors will produce different key
spaces for the same root map and set of active filtering conditions.

We probably need to make this last paragraph part of the specification just
to keep things clear(er).

Cheers,

E.

On 2/8/11 4:23 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote:

> 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
>  <http://www.sdl.com/innovate>
> 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 <mailto:syeo@justsystems.com>
> 
>  
> 
>  

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com