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


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



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