[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 Space Determination?
|
This is an order of processing issue, although we try to
avoid mandating processing order or methods in favor of stating what the
required or desired result should or must be. We didn't address order of processing issues or the
effect of conditional processing on Key References when we voted on issue
#12007. We probably should have, but we didn't. The DITA spec. has never really talked about order of
processing issues or the required results. 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). The DITA 1.0, 1.1, and so far 1.2 specs. have not
addressed these issues. Adding them to DITA 1.2 really requires some
thoughtful consideration, a proposal, and ultimately a vote by the DITA
TC. That will take time and effort. If we want to take that time
and effort now, then we can consider making this a MUST item. If we
don't, the spec. can either remain silent on the issues or we can make it a
SHOULD item. SHOULD is my preference. It gives everyone a statement
of direction without putting implementations that were in compliance out of
compliance. You can look at this in at least two different ways: 1. Making
this a SHOULD rather than a MUST requirement is a failure; or 2. Making
this a SHOULD requirement rather than a MUST is an improvement that can be
further improved in DITA 1.3. By the way, I am not making this argument because of
anything that the Arbortext Editor implementation does or does not do as far as
Key Reference processing. I believe that we will implement conditional
processing and Key References to meet the SHOULD requirement. I am less
sure that our key reference processing will be correct with respect to all
other order of processing issues (cascading, conref, conditional processing, …),
simply because the spec. is silent on those issues and so I’m not sure
that the desired behavior is. We have made what are hopefully informed
guesses and implemented something. I can imagine that once the TC states what
the desired behavior for all of this is, that we’ll need to make some
changes. It is unclear how much work will be involvedand therefore how quickly
any changes can be made. Or perhaps we’ll be lucky and our guesses will
turn out to have been right and we won’t need to make any adjustments at
all. -Jeff > -----Original Message----- > From: Gershon Joseph (gerjosep) [mailto:gerjosep@cisco.com] > Sent: Tuesday, November 03, 2009 7:07 AM > To: ekimber; Ogden, Jeff; dita > Cc: Robert D Anderson > Subject: RE: [dita] Potential Issue: When Does Applicability Apply to > Key Space Determination? > > I agree with Eliot that we need to say "must" to ensure all > implementations are indeed interchangeable. > > > -- > Gershon > > -----Original Message----- > From: ekimber [mailto:ekimber@reallysi.com] > Sent: Monday, November 02, 2009 11:34 PM > To: Ogden, Jeff; dita > Cc: Robert D Anderson > 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> > > > --------------------------------------------------------------------- > 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]