[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?
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]