Re: [dita] Potential Issue: When Does Applicability Apply to Key SpaceDetermination?

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

The processing order question has come up quite a few times before, and I
know that there are differences in current implementations. This means that
results may vary today, which is a known issue, and is one reason that
about 4 years ago there was already pressure to create a distinct
"Processing specification" that controlled things like the order in which
different core pieces of DITA were implemented. For example - filtering,
conref resolution, pulling of content into <xref> elements, and addition of
contextual links based on a map.

Keyref is new, so I think that the specification is within its rights to
declare that filtering must be done before or after keys are determined.
For other items like conref, I think we are stuck with "Should" being the
strongest language we use, otherwise we will break existing DITA compliant
tools.

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

ekimber <ekimber@reallysi.com> wrote on 11/02/2009 04:33:48 PM:

> ekimber <ekimber@reallysi.com>
> 11/02/2009 04:33 PM
>
> To
>
> "Ogden, Jeff" <jogden@ptc.com>, dita <dita@lists.oasis-open.org>
>
> cc
>
> Robert D Anderson/Rochester/IBM@IBMUS
>
> Subject
>
> Re: [dita] Potential Issue: When Does Applicability Apply to Key
> Space Determination?
>
> On 11/2/09 5:18 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:
>
> > Eliot asked:
> >
> >> So I guess we really have two questions:
> >>
> >
> >> 1. Does anyone disagree with the assertion that "filter first"
> >> is/should be the working principle of the DITA 1.2 standard?
> >
> > I agree with this, but feel that because this is coming so late in the
> > DITA 1.2 cycle and because the DITA 1.0, 1.1, and up until now DITA 1.2
> > specs have been silent about order of processing issues, that if we are
> > going to include this in DITA 1.2 that it should be a SHOULD rather
than
> > a MUST.
> >
> >> 2. If everyone agrees that "filter first" is the principle to apply to
> >> processing generally, does anyone disagree with the conclusion that
> > key
> >
> >> spaces must therefore reflect the effect of filtering?
> >
> > I agree with this too and make the same comment about SHOULD rather
than
> > MUST in DITA 1.2.
>
> I don't see how this can be a should: there needs to be exactly one rule
for
> key space construction, otherwise there cannot be interoperability of
> processors for key-based addressing.
>
> Either filtering is *always* applied or it's *never* applied. I don't
think
> a middle ground is helpful.
>
> Since the Toolkit currently does filtering before keyspace construction,
it
> effectively requires *all* implementations to do so as well.
>
> I would be much happier, as both a tool vendor and a tool user, to have
that
> situation be formally defined by the standard rather than not. In
> particular, I don't want to be on either side of the situation where the
CMS
> or authoring tool *doesn't* apply filtering to key spaces and the Toolkit
> does. Nobody in that situation would have any authority for supporting
their
> position but they would be able to also claim that it wasn't *disallowed*
by
> the standard. That would be an impasse I'd very much like to avoid.
>
> The key mechanism is the most important thing in DITA 1.2 and the one
thing
> that is essential for DITA to be truly useful (because without it you
can't
> have both reuse and xrefs). We have to get it right.
>
> Cheers,
>
> E.
>
>
> ----
> 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>

>