[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Editorial Suggestion: Formally Define the term "root map"
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" <firstname.lastname@example.org> 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:email@example.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