dita — archive

[JoAnn Hackos <joann.hackos@comtech-serv.com>]

Hi Eliot, Can we publish it as a Adoption TC feature article or are you publishing it independently? JoAnn On 1/23/11 6:40 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > I'm drafting such an article now. > > Cheers, > > E. > > On 1/22/11 11:23 AM, "Joann Hackos" <joann.hackos@comtech-serv.com> wrote: > >> If the interpretation of the language is so difficult, we ought to consider >> developing a graphical representation to show the relationships and hierarchy >> more clearly. I¹d like to see someone create a feature article for the >> Adoption TC. We might even be able to get it published. >> >> By the way, I¹m hearing the same questions from other CMS vendors. And, some >> very wrong assumptions about the placement of the key files. >> >> JoAnn >> >> >> On 1/21/11 9:15 AM, "Kristen Eberlein" <keberlein@sdl.com> wrote: >> >>> 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 < mailto:keberlein@sdl.com > >>> < http://www.sdl.com/ > >>> Please consider the environment before printing this e-mail >>> >>>