[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Question about order in which keys are resolved
Oops! Forget (n). "A root map and its directly addressed, local scope descendant maps establish a unique key space" and "a map tree is determined by considering only directly addressed, local scope maps descending from the root map". > -----Original Message----- > From: Bruce Nevin (bnevin) > Sent: Friday, January 21, 2011 2:28 PM > To: Eliot Kimber; Nitchie, Chris; Kristen Eberlein; dita > Cc: Mark DeVries > Subject: RE: [dita] Question about order in which keys are resolved > > Should we understand "after that" or sequential "then" before > your second sentence? > "Then the submaps that constitute the key space map tree are > processed in breadth first order." > So that key definitions in a map are all considered before > those in any of its submaps? > > 1. Key definitions in the root map, in document order. > 2. Key definitions in the (breadth-first) first submap in the > root map, in document order. > 3. Key definitions in the (breadth-first) second submap in > the root map, in document order. > ... > n. Key definitions in the first submap of the submap in (2), > in document order. > ... > > > -----Original Message----- > > From: Eliot Kimber [mailto:ekimber@reallysi.com] > > Sent: Friday, January 21, 2011 1:37 PM > > To: Nitchie, Chris; Kristen Eberlein; dita > > Cc: Mark DeVries > > Subject: Re: [dita] Question about order in which keys are resolved > > > > Chris has it backwards: > > > > Key definitions within a given map document are processed > in document > > (depth > > first) order. The submaps that constitute the key space map > tree are > > processed in breadth first order. > > > > This has the effect that, within a map, the first > definition of a key > > wins, and within the map tree, the "highest" > > (nearest to the root map) wins, explicitly allowing using maps to > > override key definitions in used maps. > > > > Cheers, > > > > E. > > > > On 1/21/11 11:37 AM, "Nitchie, Chris" <cnitchie@ptc.com> wrote: > > > > > Kris, > > > > > > At the bottom of the same topic under ³Effective Key > Definitions,² > > > thereıs this (emphasis added): > > > > > > <quote> > > > Effective key definitions > > > For a given key there is at most one effective definition > > within a key space. > > > A key definition is the effective definition for a given > > key if it is > > > the first, in document order, within the map document > that contains > > > it, and is the first in the map tree in breadth-first > > order. It is not > > > an error for the same key name to be defined more than once > > within a > > > map or map tree, and duplicate key definitions should be > > ignored without warning. > > > </quote> > > > > > > I take the spec to say that sub-maps are processed in > > document order, > > > but key definitions within the same map are determined in > > > breadth-first order. So, to use your example map, if B and > > A.1 both > > > defined the same key name, then B would be the effective > > definition. > > > But if B and A.1 were both references to sub-maps, A.1 > > would be processed before B. > > > > > > Where things get fuzzy for me is when A.1 is a reference to > > a sub-map, > > > B is a key definition, and the sub-map referred to by A.1 > > contains a > > > key definition for the same key defined on B. In that > > case, I think B > > > wins (and thatıs how weıve implemented it), but Iım only > > about 90% sure. > > > > > > Chris > > > > > > > > > From: Kristen Eberlein [mailto:keberlein@sdl.com] > > > Sent: Friday, January 21, 2011 11:16 AM > > > To: dita@lists.oasis-open.org > > > Cc: Mark DeVries > > > Subject: [dita] Question about order in which keys are resolved > > > > > > Several SDL developers have had questions pertaining to the > > order in > > > which keys are resolved. Iıve been asked whether keys are > > resolved in > > > document- or breadth-order, according to the following example: > > > > > > map > > > topicref id="A" > > > topicref id="A.1" > > > topicref id="A.1.1" > href="first-in-document-order.dita" > > > topicref id = "B" href="first-in-breadth-first-order.dita" > > > > > > Document order = A, A.1, A.1.1, B > > > Breadth-first order = A, B, A.1, A.1.1 > > > > > > My answer is that keys are resolved in document order, per the > > > following definition of ³Key spaces² in the spec: > > > Key spaces > > > A root map and its directly addressed, local scope > descendant maps > > > establish a unique key space within which each unique key > name has > > > exactly one binding to a set of resources. > > > > > > For the purposes of determining the effective key > > definitions for the > > > key space represented by a given root map, a map tree is > > determined by > > > considering only directly addressed, local scope maps > > descending from > > > the root map. The order of subordinate maps is determined by the > > > document order of the topicrefs that point to them. Indirect > > > references to maps with key references are necessarily > > ignored until after the key space is determined. > > > > > > Maps addressed by <navref> do not contribute to the key > > space of a map tree. > > > Maps referenced by <navref> are equivalent to maps > > referenced with a > > > scope of "peer" or "external" and therefore need not be > present or > > > available at the time the referencing map is processed for > > purposes of key space construction. > > > > > > Can yıall confirm that I am giving accurate guidance? > > > > > > Best regards, > > > Kris > > > Kristen James Eberlein l DITA Architect and Technical > > Specialist l SDL > > > Structured Content Technologies Division l (t) + 1 (919) > 682-2290 l > > > keberlein@sdl.com > > > <http://www.sdl.com/> > > > Please consider the environment before printing this e-mail > > > > > > > -- > > Eliot Kimber > > Senior Solutions Architect > > "Bringing Strategy, Content, and Technology Together" > > Main: 512.554.9368 > > www.reallysi.com > > 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_workgr > oups.php > > > > > > --------------------------------------------------------------------- > 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_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]