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


Hi Eliot,

> 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?

It was a considered decisions with regards to all other aspects of DITA
processing, though we did not re-examine that decision in light of keyref.
The reasoning has been discussed on this list and others, but it is
primarily based on experiences that the IBM team had in the early
(pre-standard) days of DITA. The two primary reasons to do it this way are
1) improve processing speed by dropping content you won't use as soon as
possible, and more importantly 2) do not try and retrieve content that will
never be needed. For example, if I have this:
<p conref="productA-info.dita#topic/p" product="a"/>

If I want to filter out all product A information, then I drop this early
on in my processing. The build does not retrieve productA-info.dita, which
may not even be available. The conref processing is also skipped, which
saves a bit of time.

The bigger issue for many of my own users is that when they package up
information to send off to a translator, they do not need to ship
productA-info.dita, because the conref is filtered out and never resolved.
So, no money is wasted translating the file that will not be used. This
issue, rather than the slight processing speed improvement, was the main
one that resulted in the current processing order.

As I said, when keyref came around, we didn't step back to re-address that
issue, but it does make me wonder - if you have a key definition that wins
with no ditaval, but is filtered out when you try to render the content,
how could that key still be valid in your rendered files? I guess that's
partly what you're asking. At this point I would expect the results you're
getting from the OT today, but I'm obviously thinking about this from an OT
style publishing perspective rather than from an editor or CMS perspective.

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

ekimber <ekimber@reallysi.com> wrote on 11/02/2009 02:25:28 PM:

> ekimber <ekimber@reallysi.com>
> 11/02/2009 02:25 PM
>
> To
>
> dita <dita@lists.oasis-open.org>
>
> cc
>
> Subject
>
> [dita] Potential Issue: When Does Applicability Apply to Key Space
> Determination?
>
> 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>

>
>
> ---------------------------------------------------------------------
> 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]