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: Potential Issue: When Does Applicability Apply to Key SpaceDetermination?


Something that came up in the context of a discussion I was having on how
one would normally process DITA content in the context of keys led to the
question of when conditional processing is applied to key definitions.

In particular, is filtering applied before or after the key space is
determined for a given map?

If filtering is applied before the keyspace is determined, it means that you
cannot determine a key space given just a map: you must also specify a
DITAVAL file (or its equivalent). It also means that the same map tree may
produce different key spaces for different DITAVAL files. Or rather, it
means that a key space is not simply a unique set of keys, but a unique set
of key/property pairs (where the same key may occur more than once as long
as each instance has distinct applicability).

If filtering is applied after the keyspace is determined, then you cannot
have key definitions that use conditional processing.

From an implementation standpoint, applying filtering *before* keyspace
determination significantly complicates key space calculation for systems
that just deal with keys (e.g., authoring systems) and are not doing
sequential processing of DITA content.

If filtering is done before keyspace determination it means that all
processors that work with key spaces must take as a parameter to any key
lookup both the root map *and* the set of applicable conditions or else they
have to include in any set of available keys all key definitions that have
unique applicability, that is, for a given key, the first of each definition
with a unique set of @props values, that is, the set of definitions that
*could* be effective. This would definitely complicate key space
calculation, but it could be done if the requirement is understood up front
and systems are designed to accommodate it.

If filtering is done after keyspace determination, it means that conditions
don't affect key definition (that is, a key-defining topicref that would be
filtered out is not filtered out for the purpose of defining keys).

I see that the current 1.5 Toolkit does filtering before doing any other
processing. Is that a considered decision or just the way the implementation
fell?

From a CMS and authoring tool implementation standpoint doing filtering
*after* key space determination would be easiest to implement but I suspect
that that is too limiting as it denies use of filtering for key definition
management.

Do we already have a definitive answer to this question? If not, is there
consensus about what the right answer is?

Thanks,

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> 



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