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: Rework of cascading processing rules


See my comments below.

 

Best,

Kris

 

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com

Skype: kriseberlein; voice: +1 (919) 622-1501

 

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Eliot Kimber
Sent: Tuesday, December 20, 2022 10:48 AM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Rework of cascading processing rules

 

Here’s my current attempt at a non-procedural restating of the rules for cascading:

Within the map tree that results from resolving all map references, content references, and key references, the effective value of an attribute for a given topic reference element is determined by considering both the effective direct value of the attribute and the "merged" value that reflects the effective values of ancestor elements when the effective value of @cascade is merge.

<kje>We are introducing new terminology here: “direct” and “merged” values of attributes – and I would prefer it if we could find a way to avoid doing so.</kje>

The effective direct value of an attribute is determined by the value obtained from the first of the following conditions that applies to the topicref element:

  1. The attribute value is explicitly-specified (default values set in document grammars result in explicitly-specific values following grammar-aware XML parsing).
    <kje>Do we need to distinguish between the various ways that an attribute value can be explicitly specified – specified at authoring time, fixed in the grammar files, or defaulted in the grammar files – and what takes precedence? Or is that covered by grammar-aware XML parsing?</kje>
  2. The attribute value default is defined in a controlled value file.

When the effective value of @cascade is merge, the effective merged value is determined by combining any effective direct value with the effective value for the nearest ancestor element that has an effective value (which may reflect any merging of values from ancestors). Values specified on the root elements of submaps are ignored except where the submap's root element is the only ancestor that specifies a value for the attribute. Within reltables, elements are considered to be ancestors of the elements to which they apply, making the effective ancestry of elements then then (nearest to farthest ancestor).

If an element has no effective direct or merged value, the effective value may be supplied by the processor.

<kje>What examples does the spec need to provide in order to explicate these behaviors?</kje>

Cheers,

 

E.

_____________________________________________

Eliot Kimber

Sr Staff Content Engineer

O: 512 554 9368

M: 512 554 9368

servicenow.com

LinkedIn | Twitter | YouTube | Facebook



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]