Contrasting Explanation

Here is my very broad summary of the keyscope proposal. There are two differences here tho:

1. Names here were changed to put the emphasis more on the keyspace concept.

2. The idea of a hierarchy of spaces vs only two levels is still a question for me – so I use just two levels: root and local as I feel the hiearchy case may make names more brittle when used in references – eg: inserting a scope up the tree will change the absolute names of a given keyspace.

Hopefully the exercise of a contrasting explanation can help the overall mechanism regardless of it’s final form.

In summary:

* Every key definition goes into a named key space. In DITA 1.2 one root keyspace space exists and in 1.3 we can refer to that as the current or default keyspace.

* A key space has a scope within the filtered tree (tree scope) and thus a given keydef has such a tree scope. The tree scope is either root level or is at the element which the localKeySpace attribute is attached.

* A key can be referenced using a keyspace qualifier or no such qualifier.

* There can be one or more root keyspaces which in turn can have 0 or more local keyspaces.

* To reference a key k in a local keyspace l within a root keyspace r you would use a fully qualified name of r.l.k. If the root name qualifier “r” is omitted the reference is to the current root keyspace.

* To resolve a keyref with no qualification, keyspaces which contain the keyref in their scope are used from the bottom up. This bottom up mechanism is used after the default global keyspace is checked with no match.

* Another named root level keyspace can be established by using a rootKeySpace attribute similar to (keyscope=”myname” scope=”peer”).

dita message