[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
I think the issue may be a misinterpretation of the term "map tree", which is used in this statement: 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. Map tree is defined in the preceding section titled "Key spaces": 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. (Emphasis mine) If you took "map tree" to mean "the tree of elements within a map" I can see how you might get confused. However, the statement above would be self contradictory if map tree had that meaning. I also see that "map tree" is not formally defined in the Linking and Addressing terminology section--it probably should be. At one time I think we did have an illustrative example of how key definitions work but I could simply be remembering the early work we did to define the mechanism. I certainly agree than an example or two would help to clarify things. Cheers, E. On 1/21/11 1:17 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote: > Sounds like the spec isn't clear enough here. > > First let's hear from others to make sure we all agree > on what should be the case. > > Then let's figure out how to make it clear enough in > the spec that smart people like Eliot and Chris and > Kris don't come to different conclusions reading the > same spec. > > paul > >> -----Original Message----- >> From: Eliot Kimber [mailto:ekimber@reallysi.com] >> Sent: Friday, 2011 January 21 12:37 >> 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_workgroups.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_workgroups.php > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]