OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

Innovate2011_emailsignature_final

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

 

 

JPEG image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]