[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Review #2 comments: Processing key references
The paragraph following the one Robert cites I think makes the intent clear: that you can construct a key space that holds multiple conditional key definitions and that, depending on what conditions are active when you resolve a key reference, you will get different bindings, but those bindings will be *identical to* what you would get if you had filtered first. The intent of the first sentence ("The effective keys for a map might be affected by conditional processing (filtering).") is to simply state a fact that may not be obvious: when filtering is applied the actual effective definition for a key will vary depending on the conditions applied. It does not imply that different processors can get different answers for the same set of keys and active conditions: like address resolution, there is no aspect of filtering that can vary by processor except *when* it occurs: the final result must be the same in all cases. It simply *cannot be the case* that different processors can produce different bindings for the same root map *and active conditions*. The intent of the 1.2 language is to make it clear that *if you do not filter first* the processor will have to apply filtering at key resolution time. That is, the effective binding of a given key name is dependent on the filtering conditions in effect at the time the key is resolved, either because filtering was applied first (and therefore the key space reflects exactly one set of conditions) or because filtering is applied at key resolution time. We went to great effort in 1.2 to ensure that all addressing behaviors are absolutely invariant for all possible processing conditions. So we need to do whatever we have to in 1.3 to make sure that this is clear in the spec. Note also that for 1.3 the interaction between branch filtering and key space construction is much more complicated. In particular, certain things can only happen at certain times in order to get a correct result. This has been discussed elsewhere, but it means that the simple statements about filtering and key space construction from 1.2 are not sufficient. The rules for key space construction can be derived by thinking through the process and determining what you know when (and therefore when you can or can't apply filtering or determine the key space) but we shouldn't require readers to do that. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 12/2/14, 9:19 AM, "Kristen James Eberlein" <kris@eberleinconsulting.com> wrote: > > > > > > > DITAweb URL: >https://ditaweb.com/oasis-dita/#/00074601-DA$00074010-DB$Processing%20key% >20references > > Text in question: > "he effective key definitions for > a key space might be affected by conditional processing > (filtering). Processors must perform conditional processing before > determining the effective definition for a key reference. However, > processors might determine key space contents before filtering. > Consequently, different processors might produce different > effective bindings for the same map when there are key definitions > that might be filtered out based on their filtering attributes." > > Comment from Eliot: > "This paragraph is absolutely wrong. > It cannot be the case that filtering would result > in different effective key definitions. > There are two processing possibilities: > 1. Filtering is applied to the map before key space > construction > 2. Filtering is applied to the *key space* after > key space construction > In both cases, the result of filtering MUST be the > same (that is, the spec must require that you get the same > result). > In case 1 the processing is obvious: only those > key definitions that remain after filtering are considered. > In case 2, the key space, as constructed must > maintain both the original precedence order of the key definitions > and the conditions to which each key definition applied. > When keys are resolved in the context of a case-2 > key space, the active filtering conditions must be used and thus > *exactly the same key definition* will be selected as in case 1. > Therefore the key resolution result will always be > the same for the same input map and active filtering conditions. > This is what 1.2 said and it must continue to be > true. > > Response from Robert Anderson: > "DITA 1.2 language is very similar to what we have here: "The > effective keys for a map might be affected by conditional > processing (filtering). Processors should perform conditional > processing before determining effective key definitions. However, > processors may determine effective key bindings before filtering. > Consequently, different processors might produce different > effective bindings for the same map when there are key definitions > that might be filtered out based on their select attributes." > > Referring to TC for follow-up." > > > > -- > Best, > Kris > > Kristen James Eberlein > Chair, OASIS DITA Technical Committee > Principal consultant, Eberlein Consulting > www.eberleinconsulting.com <http://www.eberleinconsulting.com> > +1 919 682-2290; kriseberlein (skype) > > > > > >--------------------------------------------------------------------- >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]