Re: [dita] Potential Issue: When Does Applicability Apply to KeySpace Determination?

[ekimber <ekimber@reallysi.com>]

On 11/3/09 8:02 AM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> Order of processing issues by their nature are interrelated. I don't
> think that you can mandate one aspect of order of processing issues
> without considering the others (how do cascading attribute values from
> map to map effect conditional processing and how does conditional
> processing effect key references to pick one example or how does the
> timing of conref processing effect cascading which effects conditional
> processing which effects key references to pick another).

But note that while we've talked about the issue in terms of processing
*order* that's not in fact what the standard would say. The standard would
say either "filtering applies to key definitions" or "filtering does not
apply to key definitions". That *implies* a processing order but doesn't
actually say anything about implementations.

It's hard to see how saying "filtering should apply to key definitions" is
better than "filtering must apply to key definitions"--in this case, because
of interoperation issues, the should is as good as a must because any
processor that didn't do it would have a hard time convincing anyone it was
doing the right thing. So why not just make the requirement a requirement?

For keys, it's clear that performing filtering at different times can have
dramatically different results.

Are there any other aspects of DITA processing for which this is true?  My
instinct is that there is not, but I would want to test that instinct
carefully, as Jeff suggests--I agree it's not something to be undertaken
lightly.

However, I think that we can make a decision about filtering and key space
determination in isolation without necessarily implying anything for any
other aspect of DITA. That is, key spaces are a thing apart, their value
completely deterministic (given a clear rule on filtering) and otherwise
independent of all other DITA processing (including map metadata
propagation). This is materially different from say rendition processing,
where a range of reasonable processes is not only allowed but expected.

That is, in the realm of addressing, there can be only one right answer for
a given input. A standard that allows different results for the same inputs
is not, I would suggest, a standard.

Also, since the Toolkit currently does filtering first, it effectively
requires that behavior of all tools that want to interoperate with the
Toolkit, which I suspect is all of them (it's hard to imagine a tool vendor
making the explicit choice to produce a different result from the Toolkit
for something as basic as key resolution).

Cheers,

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>