OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]