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] Question about order in which keys are resolved


Title: Re: [dita] Question about order in which keys are resolved
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




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