[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Definition of "root map"
There are three different cases: 1. A root map that references other maps as peers. In this case, each map retains its root map nature each root produces its own root key space. 2. Multiple root maps processed as a unit from which as *single* root keyspace is constructed. This is the case that is not allowed by the spec. 3. A single root map that includes *as local submaps* other maps and produces a single root key space. In the third case the submap titles are ignored (that is, the effective map does not reflect the titles of any of the submaps). That is almost certainly not what an author would expect or want. If you consider case 3 to be a problem it is an unavoidable side effect of the rules for how submaps are combined into an effective submap, namely that their titles are not preserved (have no effect in the output). The effect of this rule is that synthesizing a new root map over a set of what were root maps changes the behavior of DITA processors that act on the synthesized root map. The introduction of a meaning for peer map references allows you to have a single root map that includes, as peers, other root maps. This collects everything together for the purposes of establishing the dependencies without changing the root map nature of the submaps or altering the key spaces you would get from the maps processed independently. That is this: <map> <mapref scope="peer" href="root01.ditamap"/> <mapref scope="peer" href="root02.ditamap"/> </map> is fundamentally different from this: <map> <mapref scope="local" href="root01.ditamap"/> <mapref scope="local" href="root02.ditamap"/> </map> In the first case there are three root key spaces: 1. For the root map 2. For peer map root01.ditamap 3. For peer map root02.ditamap In second case there is only one root key space. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 4/6/15, 7:37 PM, "Tom Magliery" <email@example.com> wrote: >Just curious: What is the risk that is being avoided by disallowing >processors to treat multiple maps as if there were a phantom root map? > >mag > > > >-----Original Message----- >From: firstname.lastname@example.org [mailto:email@example.com] On >Behalf Of Eliot Kimber >Sent: Monday, April 06, 2015 8:20 AM >To: DITA TC >Subject: Re: [dita] Definition of "root map" > >I'm not sure how to address it in normative language, but somewhere we >have to make it clear that all key-related processing is defined >explicitly in terms of processing a single root map to produce a single >set of key spaces rooted at that one map, if that's not already made clear >in the normative discussion of keys. > >In the case of a map tree with no key scopes this means that there is an >exact one-to-one correspondence between a root map and the resulting key >space. > >In particular, a processor cannot process multiple root maps and produce a >*single* key space from them: each root map must result in a separate key >space rooted at that map. > >Or said another way: the identity of a given key space is established by >the root map and fully-qualified key scope name of that key space (where >the root key space has a null scope name [the anonymous scope]). > >With DITA 1.2 this was pretty clear I think. With DITA 1.3 and the >introduction of key scopes, which produce multiple key spaces from a >*single* map, implementors might think that they are licensed to produce a >single set of related key spaces from multiple input maps. But they are >not. > >There are also implications about the processing of map-level metadata >that apply only to root maps and not sub maps. > >For example, say a processor wanted to enable producing a single PDF file >from multiple root maps processed together. There's nothing preventing a >processor from doing that, but it will still be the case that each root >map produces its own set of key spaces and normal cross-deliverable >linking would need to be used for key references that go between root >maps--the processor is not allowed to treat all the maps *as though* there >was a single root map that included them all as submaps. > >Cheers, > >Eliot >————— >Eliot Kimber, Owner >Contrext, LLC >http://contrext.com > > > > >On 4/6/15, 9:53 AM, "Eliot Kimber" <firstname.lastname@example.org> wrote: > >>That seems like the simplest definition. >> >>Cheers, >> >>E. >>————— >>Eliot Kimber, Owner >>Contrext, LLC >>http://contrext.com >> >> >> >> >>On 4/6/15, 9:04 AM, "Kristen James Eberlein" >><email@example.com> >>wrote: >> >>> >>> >>> >>> >>> >>> >>> "Root map" is one of the terms that we use frequently in the draft >>> 1.3 spec, but the term is never formally defined. I think we need a >>> formal definition. This became very clear to me recently when I >>> encountered someone using the term "output scope" to mean what we >>> call "root map". >>> >>> Here's a strawperson definition to get us started: >>> >>> root map >>> The DITA map that is provided as input for a processor >>> >>> Basically, we are talking about "the entry point for DITA >>> map-based processing" -- Thanks to Chris Nitchie for that term. >>> >>> Eliot, I know you'll have thoughts about this. >>> >>> -- >>> Best, >>> Kris >>> >>> Kristen James Eberlein >>> Chair, OASIS DITA Technical Committee >>> Principal consultant, Eberlein Consulting >>> www.eberleinconsulting.com <http://www.eberleinconsulting.com> >>> +1 919 682-2290; kriseberlein (skype) >>> >>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>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 >> >> > > > >--------------------------------------------------------------------- >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 >