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: [mailto:] 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" <> 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" <>
>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
