Re: [dita] Editorial Suggestion: Formally Define the term "root map"

[Eliot Kimber <ekimber@reallysi.com>]

George wanted one term he could use to refer to maps used to establish
context in general, not just for key resolution. He's working toward a
general facility for identifying, within the context of projects (sets of
related files and their associated editor settings), files of different
kinds that are "roots", such as top-level DITA maps, top-level XSD
documents, top-level RelaxNG files, etc.

He's finding a general problem in XML that many standards have not defined a
specific term for "the root thing", whatever it might be.

So "key-definition context", while accurate, is not quite general enough.

But it's a challenge because if you want to define "root map" precisely, you
then have to say in what context the notion of "rootness" is meaningful or
important. That leads you to discussions of processing, which leads you to
discussions of different types processing, which opens a whole can of worms
as we well know from experience.

The notion of a "root map" is implicit in the notion of a map tree, since a
tree must have a root, and we talk about the specific map tree used for key
space construction (and its root), but we don't talk about *the* map tree in
a context-independent way because there are many ways one could view a set
of related maps as a tree and DITA currently only defines strict rules for
at most two of them (key space construction and metadata cascade).

So I'm not sure we can actually give George what he wants but I want to make
sure we've thought the issue through before saying "no".

For example, I would like to codify the notion of "publication", which I use
to mean "a map that represents the root of a single unit of publication".
Well, what is a "unit of publication"? Could mean many things. At the same
time, not all root maps are publications, so it would be inappropriate to
use "publication" as the general term.

This is one inherent challenge in writing a general-purpose application
standard: we know there are common ways that people use the data and apply
the base semantics but we have to be careful not to either limit potential
uses or privilege specific uses in our normative terminology, which tends to
lead to very general or convoluted constructions and/or lots of
non-normative explanations of what we think we mean by a term like "unit of
publication".

Hmph.

Cheers,

E.

On 4/7/11 8:16 AM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

> For what it's worth, in the new release of Arbortext Editor we use the
> term "Key Context" to refer to the root map containing key definitions
> when talking about keyref resolution.
> 
> Chris
> 
> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Thursday, April 07, 2011 9:13 AM
> To: dita
> Subject: [dita] Editorial Suggestion: Formally Define the term "root
> map"
> 
> Had an interesting discussion with George Bina from SynchroSoft on the
> general issue of how to talk about "the map that establishes the
> resolution
> context for key references". He wants to have a standard-defined term he
> can
> use in his product to refer to this map so that it's clear to users what
> he's talking about.
> 
> We looked through the current 1.2 spec and determined that we use the
> term
> "root map" consistently to mean the key-resolution-context-defining map
> but
> we never actually define the term "root map" formally, although it is
> used
> in the formal definition of the term "key resolution context".
> 
> I would like us to think about whether it makes sense, or is even
> possible,
> to define "root map" in a coherent way.
> 
> Cheers,
> 
> E.
> 
> 
> --
> 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
> 
> 
> ---------------------------------------------------------------------
> 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
> 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com