I think I was misremembering my original research. What I said in the context of the DITA OT issue that brought all this up was: "Since key scope names are used in key references they must have the same restrictions." I read through the parts of the spec that either mention or define key scopes and could find no direct language but I thought I had. Maybe Chris N. can find it. In any case, since you can override a scope-qualified key with a normal @keys value it must be the case that key scope names have the same lexical rules as key names (including allowing periods, as crazy as that might seem). For example, this should be valid: <topicref keyscope="foo.bar"> <topicref keys="baz" .../> </topicref> Meaning that keyref="foo.bar.baz" is a reference to the key "baz" in the scope "foo.bar". But we could also have in a parent scope: <topicref keys="foo.bar.baz" .../> Which overrides the scope-qualified key name "foo.bar.baz" from the descendant scope. As far as the processing is defined, the result of constructing all the key spaces is a set of key-name-to-resource bindings where each key name reflects any applicable key scopes by simple string concatenation of the key scope names to the base key names. For the purpose of resolving key references you need to know what the key scope *boundaries* are but you don't care what the key scope name is because you are simply looking up the key name you have in the current scope, which, by the processing rules, reflects all qualified and unqualified keys in the current scope, per the rules for propagating key definitions up and down the scope hierarchy. Cheers, E. ---- Eliot Kimber, Owner Contrext, LLC
http://contrext.com